Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Oleg Gelbukh]

The reason people want offline deployment feature is not because of poor
connection, but rather the enterprise intranets where getting subnet with
external access sometimes is a real pain in various body parts.

--
Best regards,
Oleg Gelbukh

On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky 
wrote:

> Hello,
>
> I agree with Vladimir - the idea of online repos is a right way to
> move. In 2015 I believe we can ignore this "poor Internet connection"
> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> distributives - most of them fetch needed packages from the Internet
> during installation, not from CD/DVD. The netboot installers are
> popular, I can't even remember when was the last time I install my
> Debian from the DVD-1 - I use netboot installer for years.
>
> Thanks,
> Igor
>
>
> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
> >
> >
> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
> wrote:
> >>
> >>
> >> Hey Vladimir,
> >>
> >>>
> >>>
> >
> > 1) There won't be such things in like [1] and [2], thus less
> > complicated flow, less errors, easier to maintain, easier to
> understand,
> > easier to troubleshoot
> > 2) If one wants to have local mirror, the flow is the same as in case
> > of upstream repos (fuel-createmirror), which is clrear for a user to
> > understand.
> 
> 
>  From the issues I've seen,  fuel-createmirror isn't very straight
>  forward and has some issues making it a bad UX.
> >>>
> >>>
> >>> I'd say the whole approach of having such tool as fuel-createmirror is
> a
> >>> way too naive. Reliable internet connection is totally up to network
> >>> engineering rather than deployment. Even using proxy is much better
> that
> >>> creating local mirror. But this discussion is totally out of the scope
> of
> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
> >>> straightforward (installed as rpm, has just a couple of command line
> >>> options). The quality of this script is also out of the scope of this
> >>> thread. BTW we have plans to improve it.
> >>
> >>
> >>
> >> Fair enough, I just wanted to raise the UX issues around these types of
> >> things as they should go into the decision making process.
> >>
> >>
> >>>
> >
> >
> > Many people still associate ISO with MOS, but it is not true when
> using
> > package based delivery approach.
> >
> > It is easy to define necessary repos during deployment and thus it is
> > easy to control what exactly is going to be installed on slave nodes.
> >
> > What do you guys think of it?
> >
> >
> 
>  Reliance on internet connectivity has been an issue since 6.1. For
> many
>  large users, complete access to the internet is not available or not
>  desired.  If we want to continue down this path, we need to improve
> the
>  tools to setup the local mirror and properly document what
> urls/ports/etc
>  need to be available for the installation of openstack and any mirror
>  creation process.  The ideal thing is to have an all-in-one CD
> similar to a
>  live cd that allows a user to completely try out fuel wherever they
> want
>  with out further requirements of internet access.  If we don't want to
>  continue with that, we need to do a better job around providing the
> tools
>  for a user to get up and running in a timely fashion.  Perhaps
> providing an
>  net-only iso and an all-included iso would be a better solution so
> people
>  will have their expectations properly set up front?
> >>>
> >>>
> >>> Let me explain why I think having local MOS mirror by default is bad:
> >>> 1) I don't see any reason why we should treat MOS  repo other way than
> >>> all other online repos. A user sees on the settings tab the list of
> repos
> >>> one of which is local by default while others are online. It can make
> user a
> >>> little bit confused, can't it? A user can be also confused by the
> fact, that
> >>> some of the repos can be cloned locally by fuel-createmirror while
> others
> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
> >>
> >>
> >>
> >> I agree. The process should be the same and it should be just another
> >> repo. It doesn't mean we can't include a version on an ISO as part of a
> >> release.  Would it be better to provide the mirror on the ISO but not
> have
> >> it enabled by default for a release so that we can gather user feedback
> on
> >> this? This would include improved documentation and possibly allowing a
> user
> >> to choose their preference so we can collect metrics?
> >>
> >>
> >>> 2) Having local MOS mirror by default makes things much more
> convoluted.
> >>> We are forced to have several directories with predefined names and we
> are
> >>> forced to manage these directories in nailgun, in upgrade script, etc.
> Why?
> >>> 3) When putting MOS mirror on 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Mike Scherbakov]

I've heard very strong requirements on having all-in-one ISO, with no
Internet access installation. Why can't we make this optional in the build
system? It should be easy to implement, is not it?

We can then consider to have this as a default option.

Igor, unfortunately
>  In 2015 I believe we can ignore this "poor Internet connection"
still not exactly true for some large enterprises. Due to all the security,
etc., there are sometimes VPNs / proxies / firewalls with very low
throughput.

I found two related bugs, but I remember there were more. I'll ask guys to
provide some exact measurements they have done as well.
https://bugs.launchpad.net/fuel/+bug/1456805
https://bugs.launchpad.net/fuel/+bug/1459089 - Ryan, can you share your
network throughput measurement / estimate?

PS. I'm all for having a way in Fuel to use another packages repos, such as
CloudArchive, etc. I just want it to be flexible.
Thanks,

On Wed, Sep 9, 2015 at 10:53 PM Igor Kalnitsky 
wrote:

> Hello,
>
> I agree with Vladimir - the idea of online repos is a right way to
> move. In 2015 I believe we can ignore this "poor Internet connection"
> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> distributives - most of them fetch needed packages from the Internet
> during installation, not from CD/DVD. The netboot installers are
> popular, I can't even remember when was the last time I install my
> Debian from the DVD-1 - I use netboot installer for years.
>
> Thanks,
> Igor
>
>
> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
> >
> >
> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
> wrote:
> >>
> >>
> >> Hey Vladimir,
> >>
> >>>
> >>>
> >
> > 1) There won't be such things in like [1] and [2], thus less
> > complicated flow, less errors, easier to maintain, easier to
> understand,
> > easier to troubleshoot
> > 2) If one wants to have local mirror, the flow is the same as in case
> > of upstream repos (fuel-createmirror), which is clrear for a user to
> > understand.
> 
> 
>  From the issues I've seen,  fuel-createmirror isn't very straight
>  forward and has some issues making it a bad UX.
> >>>
> >>>
> >>> I'd say the whole approach of having such tool as fuel-createmirror is
> a
> >>> way too naive. Reliable internet connection is totally up to network
> >>> engineering rather than deployment. Even using proxy is much better
> that
> >>> creating local mirror. But this discussion is totally out of the scope
> of
> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
> >>> straightforward (installed as rpm, has just a couple of command line
> >>> options). The quality of this script is also out of the scope of this
> >>> thread. BTW we have plans to improve it.
> >>
> >>
> >>
> >> Fair enough, I just wanted to raise the UX issues around these types of
> >> things as they should go into the decision making process.
> >>
> >>
> >>>
> >
> >
> > Many people still associate ISO with MOS, but it is not true when
> using
> > package based delivery approach.
> >
> > It is easy to define necessary repos during deployment and thus it is
> > easy to control what exactly is going to be installed on slave nodes.
> >
> > What do you guys think of it?
> >
> >
> 
>  Reliance on internet connectivity has been an issue since 6.1. For
> many
>  large users, complete access to the internet is not available or not
>  desired.  If we want to continue down this path, we need to improve
> the
>  tools to setup the local mirror and properly document what
> urls/ports/etc
>  need to be available for the installation of openstack and any mirror
>  creation process.  The ideal thing is to have an all-in-one CD
> similar to a
>  live cd that allows a user to completely try out fuel wherever they
> want
>  with out further requirements of internet access.  If we don't want to
>  continue with that, we need to do a better job around providing the
> tools
>  for a user to get up and running in a timely fashion.  Perhaps
> providing an
>  net-only iso and an all-included iso would be a better solution so
> people
>  will have their expectations properly set up front?
> >>>
> >>>
> >>> Let me explain why I think having local MOS mirror by default is bad:
> >>> 1) I don't see any reason why we should treat MOS  repo other way than
> >>> all other online repos. A user sees on the settings tab the list of
> repos
> >>> one of which is local by default while others are online. It can make
> user a
> >>> little bit confused, can't it? A user can be also confused by the
> fact, that
> >>> some of the repos can be cloned locally by fuel-createmirror while
> others
> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
> >>
> >>
> >>
> >> I agree. The process should be the same and it should be just another
> 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Adam Heczko]

Agree, we should understand taht this is not engineering decision but
rather political/business related and fully functional ISO or ISO+some
QCOW2/whatever is a strong requirement.

regards,

A.

On Thu, Sep 10, 2015 at 8:53 AM, Yaguang Tang  wrote:

>
>
> On Thu, Sep 10, 2015 at 1:52 PM, Igor Kalnitsky 
> wrote:
>
>> Hello,
>>
>> I agree with Vladimir - the idea of online repos is a right way to
>> move. In 2015 I believe we can ignore this "poor Internet connection"
>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
>> distributives - most of them fetch needed packages from the Internet
>> during installation, not from CD/DVD. The netboot installers are
>> popular, I can't even remember when was the last time I install my
>> Debian from the DVD-1 - I use netboot installer for years.
>>
>
> You are think in a way of developers, but the fact is that Fuel are widely
> used by various  enterprises in the world wide, there are many security
> policies  for enterprise to have no internet connection.
>
>
>
>> Thanks,
>> Igor
>>
>>
>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
>> >
>> >
>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
>> wrote:
>> >>
>> >>
>> >> Hey Vladimir,
>> >>
>> >>>
>> >>>
>> >
>> > 1) There won't be such things in like [1] and [2], thus less
>> > complicated flow, less errors, easier to maintain, easier to
>> understand,
>> > easier to troubleshoot
>> > 2) If one wants to have local mirror, the flow is the same as in
>> case
>> > of upstream repos (fuel-createmirror), which is clrear for a user to
>> > understand.
>> 
>> 
>>  From the issues I've seen,  fuel-createmirror isn't very straight
>>  forward and has some issues making it a bad UX.
>> >>>
>> >>>
>> >>> I'd say the whole approach of having such tool as fuel-createmirror
>> is a
>> >>> way too naive. Reliable internet connection is totally up to network
>> >>> engineering rather than deployment. Even using proxy is much better
>> that
>> >>> creating local mirror. But this discussion is totally out of the
>> scope of
>> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
>> >>> straightforward (installed as rpm, has just a couple of command line
>> >>> options). The quality of this script is also out of the scope of this
>> >>> thread. BTW we have plans to improve it.
>> >>
>> >>
>> >>
>> >> Fair enough, I just wanted to raise the UX issues around these types of
>> >> things as they should go into the decision making process.
>> >>
>> >>
>> >>>
>> >
>> >
>> > Many people still associate ISO with MOS, but it is not true when
>> using
>> > package based delivery approach.
>> >
>> > It is easy to define necessary repos during deployment and thus it
>> is
>> > easy to control what exactly is going to be installed on slave
>> nodes.
>> >
>> > What do you guys think of it?
>> >
>> >
>> 
>>  Reliance on internet connectivity has been an issue since 6.1. For
>> many
>>  large users, complete access to the internet is not available or not
>>  desired.  If we want to continue down this path, we need to improve
>> the
>>  tools to setup the local mirror and properly document what
>> urls/ports/etc
>>  need to be available for the installation of openstack and any mirror
>>  creation process.  The ideal thing is to have an all-in-one CD
>> similar to a
>>  live cd that allows a user to completely try out fuel wherever they
>> want
>>  with out further requirements of internet access.  If we don't want
>> to
>>  continue with that, we need to do a better job around providing the
>> tools
>>  for a user to get up and running in a timely fashion.  Perhaps
>> providing an
>>  net-only iso and an all-included iso would be a better solution so
>> people
>>  will have their expectations properly set up front?
>> >>>
>> >>>
>> >>> Let me explain why I think having local MOS mirror by default is bad:
>> >>> 1) I don't see any reason why we should treat MOS  repo other way than
>> >>> all other online repos. A user sees on the settings tab the list of
>> repos
>> >>> one of which is local by default while others are online. It can make
>> user a
>> >>> little bit confused, can't it? A user can be also confused by the
>> fact, that
>> >>> some of the repos can be cloned locally by fuel-createmirror while
>> others
>> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
>> >>
>> >>
>> >>
>> >> I agree. The process should be the same and it should be just another
>> >> repo. It doesn't mean we can't include a version on an ISO as part of a
>> >> release.  Would it be better to provide the mirror on the ISO but not
>> have
>> >> it enabled by default for a release so that we can gather user
>> feedback on
>> >> this? This would include improved documentation and 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Yaguang Tang]

On Thu, Sep 10, 2015 at 1:52 PM, Igor Kalnitsky 
wrote:

> Hello,
>
> I agree with Vladimir - the idea of online repos is a right way to
> move. In 2015 I believe we can ignore this "poor Internet connection"
> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> distributives - most of them fetch needed packages from the Internet
> during installation, not from CD/DVD. The netboot installers are
> popular, I can't even remember when was the last time I install my
> Debian from the DVD-1 - I use netboot installer for years.
>

You are think in a way of developers, but the fact is that Fuel are widely
used by various  enterprises in the world wide, there are many security
policies  for enterprise to have no internet connection.



> Thanks,
> Igor
>
>
> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
> >
> >
> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
> wrote:
> >>
> >>
> >> Hey Vladimir,
> >>
> >>>
> >>>
> >
> > 1) There won't be such things in like [1] and [2], thus less
> > complicated flow, less errors, easier to maintain, easier to
> understand,
> > easier to troubleshoot
> > 2) If one wants to have local mirror, the flow is the same as in case
> > of upstream repos (fuel-createmirror), which is clrear for a user to
> > understand.
> 
> 
>  From the issues I've seen,  fuel-createmirror isn't very straight
>  forward and has some issues making it a bad UX.
> >>>
> >>>
> >>> I'd say the whole approach of having such tool as fuel-createmirror is
> a
> >>> way too naive. Reliable internet connection is totally up to network
> >>> engineering rather than deployment. Even using proxy is much better
> that
> >>> creating local mirror. But this discussion is totally out of the scope
> of
> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
> >>> straightforward (installed as rpm, has just a couple of command line
> >>> options). The quality of this script is also out of the scope of this
> >>> thread. BTW we have plans to improve it.
> >>
> >>
> >>
> >> Fair enough, I just wanted to raise the UX issues around these types of
> >> things as they should go into the decision making process.
> >>
> >>
> >>>
> >
> >
> > Many people still associate ISO with MOS, but it is not true when
> using
> > package based delivery approach.
> >
> > It is easy to define necessary repos during deployment and thus it is
> > easy to control what exactly is going to be installed on slave nodes.
> >
> > What do you guys think of it?
> >
> >
> 
>  Reliance on internet connectivity has been an issue since 6.1. For
> many
>  large users, complete access to the internet is not available or not
>  desired.  If we want to continue down this path, we need to improve
> the
>  tools to setup the local mirror and properly document what
> urls/ports/etc
>  need to be available for the installation of openstack and any mirror
>  creation process.  The ideal thing is to have an all-in-one CD
> similar to a
>  live cd that allows a user to completely try out fuel wherever they
> want
>  with out further requirements of internet access.  If we don't want to
>  continue with that, we need to do a better job around providing the
> tools
>  for a user to get up and running in a timely fashion.  Perhaps
> providing an
>  net-only iso and an all-included iso would be a better solution so
> people
>  will have their expectations properly set up front?
> >>>
> >>>
> >>> Let me explain why I think having local MOS mirror by default is bad:
> >>> 1) I don't see any reason why we should treat MOS  repo other way than
> >>> all other online repos. A user sees on the settings tab the list of
> repos
> >>> one of which is local by default while others are online. It can make
> user a
> >>> little bit confused, can't it? A user can be also confused by the
> fact, that
> >>> some of the repos can be cloned locally by fuel-createmirror while
> others
> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
> >>
> >>
> >>
> >> I agree. The process should be the same and it should be just another
> >> repo. It doesn't mean we can't include a version on an ISO as part of a
> >> release.  Would it be better to provide the mirror on the ISO but not
> have
> >> it enabled by default for a release so that we can gather user feedback
> on
> >> this? This would include improved documentation and possibly allowing a
> user
> >> to choose their preference so we can collect metrics?
> >>
> >>
> >>> 2) Having local MOS mirror by default makes things much more
> convoluted.
> >>> We are forced to have several directories with predefined names and we
> are
> >>> forced to manage these directories in nailgun, in upgrade script, etc.
> Why?
> >>> 3) When putting MOS mirror on ISO, we make people think that ISO is

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Adam Heczko]

Folks, what I can see is that most of you represent 'engineering' point of
view.
Way of installing OpenStack by Fuel is not 'engineering' decision - it is
political and business related decision.
I believe that possibility to get fully working / not internet dependent
ISO or ISO + some additional let's say QCOW2 disk image, holding all
necessary stuff required to deploy OpenStack is crucial determinant factor
to most of enterprise customers.
This is absolutely not internet connectivity related, this is not technical
question, we are touching philosophical approach to software distribution
approach and way of understanding of things by all kind of 'C' grade
managers.
In order OpenStack to succeed, 'no internet connectivity' approach is a
must have.
If not directly from within ISO, then we have to provide easy to use and
understand guidance how to deploy OS without any internet connectivity,
e.g. fuel-createmirror or other similar scripts.

Regards,

A.


On Thu, Sep 10, 2015 at 7:52 AM, Igor Kalnitsky 
wrote:

> Hello,
>
> I agree with Vladimir - the idea of online repos is a right way to
> move. In 2015 I believe we can ignore this "poor Internet connection"
> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> distributives - most of them fetch needed packages from the Internet
> during installation, not from CD/DVD. The netboot installers are
> popular, I can't even remember when was the last time I install my
> Debian from the DVD-1 - I use netboot installer for years.
>
> Thanks,
> Igor
>
>
> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
> >
> >
> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
> wrote:
> >>
> >>
> >> Hey Vladimir,
> >>
> >>>
> >>>
> >
> > 1) There won't be such things in like [1] and [2], thus less
> > complicated flow, less errors, easier to maintain, easier to
> understand,
> > easier to troubleshoot
> > 2) If one wants to have local mirror, the flow is the same as in case
> > of upstream repos (fuel-createmirror), which is clrear for a user to
> > understand.
> 
> 
>  From the issues I've seen,  fuel-createmirror isn't very straight
>  forward and has some issues making it a bad UX.
> >>>
> >>>
> >>> I'd say the whole approach of having such tool as fuel-createmirror is
> a
> >>> way too naive. Reliable internet connection is totally up to network
> >>> engineering rather than deployment. Even using proxy is much better
> that
> >>> creating local mirror. But this discussion is totally out of the scope
> of
> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
> >>> straightforward (installed as rpm, has just a couple of command line
> >>> options). The quality of this script is also out of the scope of this
> >>> thread. BTW we have plans to improve it.
> >>
> >>
> >>
> >> Fair enough, I just wanted to raise the UX issues around these types of
> >> things as they should go into the decision making process.
> >>
> >>
> >>>
> >
> >
> > Many people still associate ISO with MOS, but it is not true when
> using
> > package based delivery approach.
> >
> > It is easy to define necessary repos during deployment and thus it is
> > easy to control what exactly is going to be installed on slave nodes.
> >
> > What do you guys think of it?
> >
> >
> 
>  Reliance on internet connectivity has been an issue since 6.1. For
> many
>  large users, complete access to the internet is not available or not
>  desired.  If we want to continue down this path, we need to improve
> the
>  tools to setup the local mirror and properly document what
> urls/ports/etc
>  need to be available for the installation of openstack and any mirror
>  creation process.  The ideal thing is to have an all-in-one CD
> similar to a
>  live cd that allows a user to completely try out fuel wherever they
> want
>  with out further requirements of internet access.  If we don't want to
>  continue with that, we need to do a better job around providing the
> tools
>  for a user to get up and running in a timely fashion.  Perhaps
> providing an
>  net-only iso and an all-included iso would be a better solution so
> people
>  will have their expectations properly set up front?
> >>>
> >>>
> >>> Let me explain why I think having local MOS mirror by default is bad:
> >>> 1) I don't see any reason why we should treat MOS  repo other way than
> >>> all other online repos. A user sees on the settings tab the list of
> repos
> >>> one of which is local by default while others are online. It can make
> user a
> >>> little bit confused, can't it? A user can be also confused by the
> fact, that
> >>> some of the repos can be cloned locally by fuel-createmirror while
> others
> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
> >>
> >>
> >>
> >> I agree. The process 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Igor Kalnitsky]

Mike,

> still not exactly true for some large enterprises. Due to all the security, 
> etc.,
> there are sometimes VPNs / proxies / firewalls with very low throughput.

It's their problem, and their policies. We can't and shouldn't handle
all possible cases. If some enterprise has "no Internet" policy, I bet
it won't be a problem for their IT guys to create an intranet mirror
for MOS packages. Moreover, I also bet they do have a mirror for
Ubuntu or other Linux distributive. So it basically about approach how
to consume our mirrors.

On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin  wrote:
> Folks
>
> I think, Mike is completely right here - we need an option to build
> all-in-one ISO which can be tried-out/deployed unattendedly without internet
> access. Let's let a user make a choice what he wants, not push him into
> embarassing situation. We still have many parts of Fuel which make choices
> for user that cannot be overriden. Let's not pretend that we know more than
> user does about his environment.
>
> On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
> wrote:
>>
>> The reason people want offline deployment feature is not because of poor
>> connection, but rather the enterprise intranets where getting subnet with
>> external access sometimes is a real pain in various body parts.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky 
>> wrote:
>>>
>>> Hello,
>>>
>>> I agree with Vladimir - the idea of online repos is a right way to
>>> move. In 2015 I believe we can ignore this "poor Internet connection"
>>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
>>> distributives - most of them fetch needed packages from the Internet
>>> during installation, not from CD/DVD. The netboot installers are
>>> popular, I can't even remember when was the last time I install my
>>> Debian from the DVD-1 - I use netboot installer for years.
>>>
>>> Thanks,
>>> Igor
>>>
>>>
>>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
>>> >
>>> >
>>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
>>> > wrote:
>>> >>
>>> >>
>>> >> Hey Vladimir,
>>> >>
>>> >>>
>>> >>>
>>> >
>>> > 1) There won't be such things in like [1] and [2], thus less
>>> > complicated flow, less errors, easier to maintain, easier to
>>> > understand,
>>> > easier to troubleshoot
>>> > 2) If one wants to have local mirror, the flow is the same as in
>>> > case
>>> > of upstream repos (fuel-createmirror), which is clrear for a user
>>> > to
>>> > understand.
>>> 
>>> 
>>>  From the issues I've seen,  fuel-createmirror isn't very straight
>>>  forward and has some issues making it a bad UX.
>>> >>>
>>> >>>
>>> >>> I'd say the whole approach of having such tool as fuel-createmirror
>>> >>> is a
>>> >>> way too naive. Reliable internet connection is totally up to network
>>> >>> engineering rather than deployment. Even using proxy is much better
>>> >>> that
>>> >>> creating local mirror. But this discussion is totally out of the
>>> >>> scope of
>>> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
>>> >>> straightforward (installed as rpm, has just a couple of command line
>>> >>> options). The quality of this script is also out of the scope of this
>>> >>> thread. BTW we have plans to improve it.
>>> >>
>>> >>
>>> >>
>>> >> Fair enough, I just wanted to raise the UX issues around these types
>>> >> of
>>> >> things as they should go into the decision making process.
>>> >>
>>> >>
>>> >>>
>>> >
>>> >
>>> > Many people still associate ISO with MOS, but it is not true when
>>> > using
>>> > package based delivery approach.
>>> >
>>> > It is easy to define necessary repos during deployment and thus it
>>> > is
>>> > easy to control what exactly is going to be installed on slave
>>> > nodes.
>>> >
>>> > What do you guys think of it?
>>> >
>>> >
>>> 
>>>  Reliance on internet connectivity has been an issue since 6.1. For
>>>  many
>>>  large users, complete access to the internet is not available or not
>>>  desired.  If we want to continue down this path, we need to improve
>>>  the
>>>  tools to setup the local mirror and properly document what
>>>  urls/ports/etc
>>>  need to be available for the installation of openstack and any
>>>  mirror
>>>  creation process.  The ideal thing is to have an all-in-one CD
>>>  similar to a
>>>  live cd that allows a user to completely try out fuel wherever they
>>>  want
>>>  with out further requirements of internet access.  If we don't want
>>>  to
>>>  continue with that, we need to do a better job around providing the
>>>  tools
>>>  for a user to get up and running in a timely fashion.  Perhaps
>>>  providing an
>>>  

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kuklin]

Folks

I think, Mike is completely right here - we need an option to build
all-in-one ISO which can be tried-out/deployed unattendedly without
internet access. Let's let a user make a choice what he wants, not push him
into embarassing situation. We still have many parts of Fuel which make
choices for user that cannot be overriden. Let's not pretend that we know
more than user does about his environment.

On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
wrote:

> The reason people want offline deployment feature is not because of poor
> connection, but rather the enterprise intranets where getting subnet with
> external access sometimes is a real pain in various body parts.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky 
> wrote:
>
>> Hello,
>>
>> I agree with Vladimir - the idea of online repos is a right way to
>> move. In 2015 I believe we can ignore this "poor Internet connection"
>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
>> distributives - most of them fetch needed packages from the Internet
>> during installation, not from CD/DVD. The netboot installers are
>> popular, I can't even remember when was the last time I install my
>> Debian from the DVD-1 - I use netboot installer for years.
>>
>> Thanks,
>> Igor
>>
>>
>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
>> >
>> >
>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 
>> wrote:
>> >>
>> >>
>> >> Hey Vladimir,
>> >>
>> >>>
>> >>>
>> >
>> > 1) There won't be such things in like [1] and [2], thus less
>> > complicated flow, less errors, easier to maintain, easier to
>> understand,
>> > easier to troubleshoot
>> > 2) If one wants to have local mirror, the flow is the same as in
>> case
>> > of upstream repos (fuel-createmirror), which is clrear for a user to
>> > understand.
>> 
>> 
>>  From the issues I've seen,  fuel-createmirror isn't very straight
>>  forward and has some issues making it a bad UX.
>> >>>
>> >>>
>> >>> I'd say the whole approach of having such tool as fuel-createmirror
>> is a
>> >>> way too naive. Reliable internet connection is totally up to network
>> >>> engineering rather than deployment. Even using proxy is much better
>> that
>> >>> creating local mirror. But this discussion is totally out of the
>> scope of
>> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
>> >>> straightforward (installed as rpm, has just a couple of command line
>> >>> options). The quality of this script is also out of the scope of this
>> >>> thread. BTW we have plans to improve it.
>> >>
>> >>
>> >>
>> >> Fair enough, I just wanted to raise the UX issues around these types of
>> >> things as they should go into the decision making process.
>> >>
>> >>
>> >>>
>> >
>> >
>> > Many people still associate ISO with MOS, but it is not true when
>> using
>> > package based delivery approach.
>> >
>> > It is easy to define necessary repos during deployment and thus it
>> is
>> > easy to control what exactly is going to be installed on slave
>> nodes.
>> >
>> > What do you guys think of it?
>> >
>> >
>> 
>>  Reliance on internet connectivity has been an issue since 6.1. For
>> many
>>  large users, complete access to the internet is not available or not
>>  desired.  If we want to continue down this path, we need to improve
>> the
>>  tools to setup the local mirror and properly document what
>> urls/ports/etc
>>  need to be available for the installation of openstack and any mirror
>>  creation process.  The ideal thing is to have an all-in-one CD
>> similar to a
>>  live cd that allows a user to completely try out fuel wherever they
>> want
>>  with out further requirements of internet access.  If we don't want
>> to
>>  continue with that, we need to do a better job around providing the
>> tools
>>  for a user to get up and running in a timely fashion.  Perhaps
>> providing an
>>  net-only iso and an all-included iso would be a better solution so
>> people
>>  will have their expectations properly set up front?
>> >>>
>> >>>
>> >>> Let me explain why I think having local MOS mirror by default is bad:
>> >>> 1) I don't see any reason why we should treat MOS  repo other way than
>> >>> all other online repos. A user sees on the settings tab the list of
>> repos
>> >>> one of which is local by default while others are online. It can make
>> user a
>> >>> little bit confused, can't it? A user can be also confused by the
>> fact, that
>> >>> some of the repos can be cloned locally by fuel-createmirror while
>> others
>> >>> can't. That is not straightforward, NOT fuel-createmirror UX.
>> >>
>> >>
>> >>
>> >> I agree. The process should be the same and it should be just another
>> >> repo. It doesn't mean we can't include a 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kuklin]

Igor

Having poor access to the internet is a regular use case which we must
support. This is not a crazy requirement. Not having full ISO makes cloud
setup harder to complete. Even more, not having hard requirement to create
a mirror will detract newcomers. I can say that if I were a user and saw a
requirement to create mirror I would not try the product with comparison to
the case when I can get a full ISO with all the stuff I need.

On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Guys,
>
> I really appreciate your opinions on whether Fuel should be all inclusive
> or not. But the original topic of this thread is different. I personally
> think that in 2015 it is not a big deal to make the master node able to
> access any online host (even taking into account paranoid security
> policies). It is just a matter of network engineering. But it is completely
> out of the scope. What I am suggesting is to align the way how we treat
> different repos, whether upstream or MOS. What I am working on right now is
> I am trying to make Fuel build and delivery approach really flexible. That
> means we need to have as little non-standard ways/hacks/approaches/options
> as possible.
>
> > Why can't we make this optional in the build system? It should be easy
> to implement, is not it?
>
> That is exactly what I am trying to do (make it optional). But I don't
> want it to be yet another boolean variable for this particular thing (MOS
> repo). We have working approach for dealing with repos. Repos can either
> online or local mirrors. We have a tool for making local mirrors
> (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
> deploy OpenStack, because he/she still needs upstream to be available.
> Anyway, the user is still forced to do some additional actions. Again, we
> have plans to improve the quality and UX of fuel-createmirror.
>
> Yet another thing I don't want to be on the master node is a bunch of MOS
> repos directories named like
> /var/www/nailgun/2015.1-7.0
> /var/www/nailgun/2014.4-6.1
> with links like
> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
> What does this link mean? Even Fuel developers can be confused. It is
> scary to imagine what users think of it :-) Why should Nailgun and upgrade
> script manage that kind of storage in this exact kind of format? A long
> time ago people invented RPM/DEB repositories, tools to manage them and
> structure for versioning them. We have Perestoika for that and we have
> plans to put all package/mirror related tools in one place (
> github.com/stackforge/fuel-mirror) and make all these tools available out
> of Fuel CI. So, users will be able to easily build their own packages,
> clone necessary repos and manage them in the way which is standard in the
> industry. However, it is out of the scope of the letter.
>
> I also don't like the idea of putting MOS repo on the ISO by default
> because it encourages people thing that ISO is the way of distributing MOS.
> ISO should be nothing more than just a way of installing Fuel from scratch.
> MOS should be distributed via MOS repos. Fuel is available as RPM package
> in RPM MOS repo.
>
>
>
>
>
>
>
> Vladimir Kozhukalov
>
> On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky 
> wrote:
>
>> Mike,
>>
>> > still not exactly true for some large enterprises. Due to all the
>> security, etc.,
>> > there are sometimes VPNs / proxies / firewalls with very low throughput.
>>
>> It's their problem, and their policies. We can't and shouldn't handle
>> all possible cases. If some enterprise has "no Internet" policy, I bet
>> it won't be a problem for their IT guys to create an intranet mirror
>> for MOS packages. Moreover, I also bet they do have a mirror for
>> Ubuntu or other Linux distributive. So it basically about approach how
>> to consume our mirrors.
>>
>> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin 
>> wrote:
>> > Folks
>> >
>> > I think, Mike is completely right here - we need an option to build
>> > all-in-one ISO which can be tried-out/deployed unattendedly without
>> internet
>> > access. Let's let a user make a choice what he wants, not push him into
>> > embarassing situation. We still have many parts of Fuel which make
>> choices
>> > for user that cannot be overriden. Let's not pretend that we know more
>> than
>> > user does about his environment.
>> >
>> > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
>> > wrote:
>> >>
>> >> The reason people want offline deployment feature is not because of
>> poor
>> >> connection, but rather the enterprise intranets where getting subnet
>> with
>> >> external access sometimes is a real pain in various body parts.
>> >>
>> >> --
>> >> Best regards,
>> >> Oleg Gelbukh
>> >>
>> >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <
>> ikalnit...@mirantis.com>
>> >> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I agree with Vladimir - the 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kuklin]

Igor

This is not the case to tell users if they are stupid are not. We are
working for our users, not vice versa.

On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky 
wrote:

> Mike,
>
> > still not exactly true for some large enterprises. Due to all the
> security, etc.,
> > there are sometimes VPNs / proxies / firewalls with very low throughput.
>
> It's their problem, and their policies. We can't and shouldn't handle
> all possible cases. If some enterprise has "no Internet" policy, I bet
> it won't be a problem for their IT guys to create an intranet mirror
> for MOS packages. Moreover, I also bet they do have a mirror for
> Ubuntu or other Linux distributive. So it basically about approach how
> to consume our mirrors.
>
> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin 
> wrote:
> > Folks
> >
> > I think, Mike is completely right here - we need an option to build
> > all-in-one ISO which can be tried-out/deployed unattendedly without
> internet
> > access. Let's let a user make a choice what he wants, not push him into
> > embarassing situation. We still have many parts of Fuel which make
> choices
> > for user that cannot be overriden. Let's not pretend that we know more
> than
> > user does about his environment.
> >
> > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
> > wrote:
> >>
> >> The reason people want offline deployment feature is not because of poor
> >> connection, but rather the enterprise intranets where getting subnet
> with
> >> external access sometimes is a real pain in various body parts.
> >>
> >> --
> >> Best regards,
> >> Oleg Gelbukh
> >>
> >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <
> ikalnit...@mirantis.com>
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I agree with Vladimir - the idea of online repos is a right way to
> >>> move. In 2015 I believe we can ignore this "poor Internet connection"
> >>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> >>> distributives - most of them fetch needed packages from the Internet
> >>> during installation, not from CD/DVD. The netboot installers are
> >>> popular, I can't even remember when was the last time I install my
> >>> Debian from the DVD-1 - I use netboot installer for years.
> >>>
> >>> Thanks,
> >>> Igor
> >>>
> >>>
> >>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang 
> wrote:
> >>> >
> >>> >
> >>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz  >
> >>> > wrote:
> >>> >>
> >>> >>
> >>> >> Hey Vladimir,
> >>> >>
> >>> >>>
> >>> >>>
> >>> >
> >>> > 1) There won't be such things in like [1] and [2], thus less
> >>> > complicated flow, less errors, easier to maintain, easier to
> >>> > understand,
> >>> > easier to troubleshoot
> >>> > 2) If one wants to have local mirror, the flow is the same as in
> >>> > case
> >>> > of upstream repos (fuel-createmirror), which is clrear for a user
> >>> > to
> >>> > understand.
> >>> 
> >>> 
> >>>  From the issues I've seen,  fuel-createmirror isn't very straight
> >>>  forward and has some issues making it a bad UX.
> >>> >>>
> >>> >>>
> >>> >>> I'd say the whole approach of having such tool as fuel-createmirror
> >>> >>> is a
> >>> >>> way too naive. Reliable internet connection is totally up to
> network
> >>> >>> engineering rather than deployment. Even using proxy is much better
> >>> >>> that
> >>> >>> creating local mirror. But this discussion is totally out of the
> >>> >>> scope of
> >>> >>> this letter. Currently,  we have fuel-createmirror and it is pretty
> >>> >>> straightforward (installed as rpm, has just a couple of command
> line
> >>> >>> options). The quality of this script is also out of the scope of
> this
> >>> >>> thread. BTW we have plans to improve it.
> >>> >>
> >>> >>
> >>> >>
> >>> >> Fair enough, I just wanted to raise the UX issues around these types
> >>> >> of
> >>> >> things as they should go into the decision making process.
> >>> >>
> >>> >>
> >>> >>>
> >>> >
> >>> >
> >>> > Many people still associate ISO with MOS, but it is not true when
> >>> > using
> >>> > package based delivery approach.
> >>> >
> >>> > It is easy to define necessary repos during deployment and thus
> it
> >>> > is
> >>> > easy to control what exactly is going to be installed on slave
> >>> > nodes.
> >>> >
> >>> > What do you guys think of it?
> >>> >
> >>> >
> >>> 
> >>>  Reliance on internet connectivity has been an issue since 6.1. For
> >>>  many
> >>>  large users, complete access to the internet is not available or
> not
> >>>  desired.  If we want to continue down this path, we need to
> improve
> >>>  the
> >>>  tools to setup the local mirror and properly document what
> >>>  urls/ports/etc
> >>>  need to be available for the installation of openstack and any
> >>>  mirror
> >>> 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Guys,

I really appreciate your opinions on whether Fuel should be all inclusive
or not. But the original topic of this thread is different. I personally
think that in 2015 it is not a big deal to make the master node able to
access any online host (even taking into account paranoid security
policies). It is just a matter of network engineering. But it is completely
out of the scope. What I am suggesting is to align the way how we treat
different repos, whether upstream or MOS. What I am working on right now is
I am trying to make Fuel build and delivery approach really flexible. That
means we need to have as little non-standard ways/hacks/approaches/options
as possible.

> Why can't we make this optional in the build system? It should be easy to
implement, is not it?

That is exactly what I am trying to do (make it optional). But I don't want
it to be yet another boolean variable for this particular thing (MOS repo).
We have working approach for dealing with repos. Repos can either online or
local mirrors. We have a tool for making local mirrors (fuel-createmirror).
Even if we put MOS on the ISO, a user still can not deploy OpenStack,
because he/she still needs upstream to be available. Anyway, the user is
still forced to do some additional actions. Again, we have plans to improve
the quality and UX of fuel-createmirror.

Yet another thing I don't want to be on the master node is a bunch of MOS
repos directories named like
/var/www/nailgun/2015.1-7.0
/var/www/nailgun/2014.4-6.1
with links like
/var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
What does this link mean? Even Fuel developers can be confused. It is scary
to imagine what users think of it :-) Why should Nailgun and upgrade script
manage that kind of storage in this exact kind of format? A long time ago
people invented RPM/DEB repositories, tools to manage them and structure
for versioning them. We have Perestoika for that and we have plans to put
all package/mirror related tools in one place (
github.com/stackforge/fuel-mirror) and make all these tools available out
of Fuel CI. So, users will be able to easily build their own packages,
clone necessary repos and manage them in the way which is standard in the
industry. However, it is out of the scope of the letter.

I also don't like the idea of putting MOS repo on the ISO by default
because it encourages people thing that ISO is the way of distributing MOS.
ISO should be nothing more than just a way of installing Fuel from scratch.
MOS should be distributed via MOS repos. Fuel is available as RPM package
in RPM MOS repo.







Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky 
wrote:

> Mike,
>
> > still not exactly true for some large enterprises. Due to all the
> security, etc.,
> > there are sometimes VPNs / proxies / firewalls with very low throughput.
>
> It's their problem, and their policies. We can't and shouldn't handle
> all possible cases. If some enterprise has "no Internet" policy, I bet
> it won't be a problem for their IT guys to create an intranet mirror
> for MOS packages. Moreover, I also bet they do have a mirror for
> Ubuntu or other Linux distributive. So it basically about approach how
> to consume our mirrors.
>
> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin 
> wrote:
> > Folks
> >
> > I think, Mike is completely right here - we need an option to build
> > all-in-one ISO which can be tried-out/deployed unattendedly without
> internet
> > access. Let's let a user make a choice what he wants, not push him into
> > embarassing situation. We still have many parts of Fuel which make
> choices
> > for user that cannot be overriden. Let's not pretend that we know more
> than
> > user does about his environment.
> >
> > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
> > wrote:
> >>
> >> The reason people want offline deployment feature is not because of poor
> >> connection, but rather the enterprise intranets where getting subnet
> with
> >> external access sometimes is a real pain in various body parts.
> >>
> >> --
> >> Best regards,
> >> Oleg Gelbukh
> >>
> >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <
> ikalnit...@mirantis.com>
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I agree with Vladimir - the idea of online repos is a right way to
> >>> move. In 2015 I believe we can ignore this "poor Internet connection"
> >>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> >>> distributives - most of them fetch needed packages from the Internet
> >>> during installation, not from CD/DVD. The netboot installers are
> >>> popular, I can't even remember when was the last time I install my
> >>> Debian from the DVD-1 - I use netboot installer for years.
> >>>
> >>> Thanks,
> >>> Igor
> >>>
> >>>
> >>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang 
> wrote:
> >>> >
> >>> >
> >>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Sergii Golovatiuk]

Vladimir,

I give my +1. We must have different repos for MOS and master node. As a
sample I am giving a case when we need to implement CentOS 7 support but
master node may remain on Centos 6.



--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Thu, Sep 10, 2015 at 3:06 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Guys,
>
> I really appreciate your opinions on whether Fuel should be all inclusive
> or not. But the original topic of this thread is different. I personally
> think that in 2015 it is not a big deal to make the master node able to
> access any online host (even taking into account paranoid security
> policies). It is just a matter of network engineering. But it is completely
> out of the scope. What I am suggesting is to align the way how we treat
> different repos, whether upstream or MOS. What I am working on right now is
> I am trying to make Fuel build and delivery approach really flexible. That
> means we need to have as little non-standard ways/hacks/approaches/options
> as possible.
>
> > Why can't we make this optional in the build system? It should be easy
> to implement, is not it?
>
> That is exactly what I am trying to do (make it optional). But I don't
> want it to be yet another boolean variable for this particular thing (MOS
> repo). We have working approach for dealing with repos. Repos can either
> online or local mirrors. We have a tool for making local mirrors
> (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
> deploy OpenStack, because he/she still needs upstream to be available.
> Anyway, the user is still forced to do some additional actions. Again, we
> have plans to improve the quality and UX of fuel-createmirror.
>
> Yet another thing I don't want to be on the master node is a bunch of MOS
> repos directories named like
> /var/www/nailgun/2015.1-7.0
> /var/www/nailgun/2014.4-6.1
> with links like
> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
> What does this link mean? Even Fuel developers can be confused. It is
> scary to imagine what users think of it :-) Why should Nailgun and upgrade
> script manage that kind of storage in this exact kind of format? A long
> time ago people invented RPM/DEB repositories, tools to manage them and
> structure for versioning them. We have Perestoika for that and we have
> plans to put all package/mirror related tools in one place (
> github.com/stackforge/fuel-mirror) and make all these tools available out
> of Fuel CI. So, users will be able to easily build their own packages,
> clone necessary repos and manage them in the way which is standard in the
> industry. However, it is out of the scope of the letter.
>
> I also don't like the idea of putting MOS repo on the ISO by default
> because it encourages people thing that ISO is the way of distributing MOS.
> ISO should be nothing more than just a way of installing Fuel from scratch.
> MOS should be distributed via MOS repos. Fuel is available as RPM package
> in RPM MOS repo.
>
>
>
>
>
>
>
> Vladimir Kozhukalov
>
> On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky 
> wrote:
>
>> Mike,
>>
>> > still not exactly true for some large enterprises. Due to all the
>> security, etc.,
>> > there are sometimes VPNs / proxies / firewalls with very low throughput.
>>
>> It's their problem, and their policies. We can't and shouldn't handle
>> all possible cases. If some enterprise has "no Internet" policy, I bet
>> it won't be a problem for their IT guys to create an intranet mirror
>> for MOS packages. Moreover, I also bet they do have a mirror for
>> Ubuntu or other Linux distributive. So it basically about approach how
>> to consume our mirrors.
>>
>> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin 
>> wrote:
>> > Folks
>> >
>> > I think, Mike is completely right here - we need an option to build
>> > all-in-one ISO which can be tried-out/deployed unattendedly without
>> internet
>> > access. Let's let a user make a choice what he wants, not push him into
>> > embarassing situation. We still have many parts of Fuel which make
>> choices
>> > for user that cannot be overriden. Let's not pretend that we know more
>> than
>> > user does about his environment.
>> >
>> > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh 
>> > wrote:
>> >>
>> >> The reason people want offline deployment feature is not because of
>> poor
>> >> connection, but rather the enterprise intranets where getting subnet
>> with
>> >> external access sometimes is a real pain in various body parts.
>> >>
>> >> --
>> >> Best regards,
>> >> Oleg Gelbukh
>> >>
>> >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <
>> ikalnit...@mirantis.com>
>> >> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I agree with Vladimir - the idea of online repos is a right way to
>> >>> move. In 2015 I believe we can ignore this "poor Internet connection"
>> >>> reason, and simplify both Fuel and UX. Moreover, take a 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Vladimir,

* We don't have full ISO anyway
* We don't require to create mirror. When you launch your browser, do you
mean to have mirror of the Internet locally? Probably, no. The same is
here. Internet connection is the common requirement nowadays, but if you
don't have one, you definitely need to have a kind of local copy.

Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin 
wrote:

> Igor
>
> Having poor access to the internet is a regular use case which we must
> support. This is not a crazy requirement. Not having full ISO makes cloud
> setup harder to complete. Even more, not having hard requirement to create
> a mirror will detract newcomers. I can say that if I were a user and saw a
> requirement to create mirror I would not try the product with comparison to
> the case when I can get a full ISO with all the stuff I need.
>
> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Guys,
>>
>> I really appreciate your opinions on whether Fuel should be all inclusive
>> or not. But the original topic of this thread is different. I personally
>> think that in 2015 it is not a big deal to make the master node able to
>> access any online host (even taking into account paranoid security
>> policies). It is just a matter of network engineering. But it is completely
>> out of the scope. What I am suggesting is to align the way how we treat
>> different repos, whether upstream or MOS. What I am working on right now is
>> I am trying to make Fuel build and delivery approach really flexible. That
>> means we need to have as little non-standard ways/hacks/approaches/options
>> as possible.
>>
>> > Why can't we make this optional in the build system? It should be easy
>> to implement, is not it?
>>
>> That is exactly what I am trying to do (make it optional). But I don't
>> want it to be yet another boolean variable for this particular thing (MOS
>> repo). We have working approach for dealing with repos. Repos can either
>> online or local mirrors. We have a tool for making local mirrors
>> (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
>> deploy OpenStack, because he/she still needs upstream to be available.
>> Anyway, the user is still forced to do some additional actions. Again, we
>> have plans to improve the quality and UX of fuel-createmirror.
>>
>> Yet another thing I don't want to be on the master node is a bunch of MOS
>> repos directories named like
>> /var/www/nailgun/2015.1-7.0
>> /var/www/nailgun/2014.4-6.1
>> with links like
>> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
>> What does this link mean? Even Fuel developers can be confused. It is
>> scary to imagine what users think of it :-) Why should Nailgun and upgrade
>> script manage that kind of storage in this exact kind of format? A long
>> time ago people invented RPM/DEB repositories, tools to manage them and
>> structure for versioning them. We have Perestoika for that and we have
>> plans to put all package/mirror related tools in one place (
>> github.com/stackforge/fuel-mirror) and make all these tools available
>> out of Fuel CI. So, users will be able to easily build their own packages,
>> clone necessary repos and manage them in the way which is standard in the
>> industry. However, it is out of the scope of the letter.
>>
>> I also don't like the idea of putting MOS repo on the ISO by default
>> because it encourages people thing that ISO is the way of distributing MOS.
>> ISO should be nothing more than just a way of installing Fuel from scratch.
>> MOS should be distributed via MOS repos. Fuel is available as RPM package
>> in RPM MOS repo.
>>
>>
>>
>>
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky 
>> wrote:
>>
>>> Mike,
>>>
>>> > still not exactly true for some large enterprises. Due to all the
>>> security, etc.,
>>> > there are sometimes VPNs / proxies / firewalls with very low
>>> throughput.
>>>
>>> It's their problem, and their policies. We can't and shouldn't handle
>>> all possible cases. If some enterprise has "no Internet" policy, I bet
>>> it won't be a problem for their IT guys to create an intranet mirror
>>> for MOS packages. Moreover, I also bet they do have a mirror for
>>> Ubuntu or other Linux distributive. So it basically about approach how
>>> to consume our mirrors.
>>>
>>> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin 
>>> wrote:
>>> > Folks
>>> >
>>> > I think, Mike is completely right here - we need an option to build
>>> > all-in-one ISO which can be tried-out/deployed unattendedly without
>>> internet
>>> > access. Let's let a user make a choice what he wants, not push him into
>>> > embarassing situation. We still have many parts of Fuel which make
>>> choices
>>> > for user that cannot be overriden. Let's not pretend that we know more
>>> than
>>> > user does about his environment.
>>> >
>>> > On 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kuklin]

Folks

I guess I need to get you on-site to deploy something at our user's
datacenter. I do want to be able to download an ISO which contains all
packages. This may not be the primary artifact of our software suite, but
we need to have this opportunity to build full ISO with ALL components.
Please, do not narrow down our feature set just by thinking that users do
not need something because we are reluctant to implement this. Just believe
me - users need this opportunity in a lot of deployment cases. It is not
hard to implement it. We do not need to set this as a default option, but
we need to have it. That is my point.

On Thu, Sep 10, 2015 at 5:40 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Vladimir,
>
> * We don't have full ISO anyway
> * We don't require to create mirror. When you launch your browser, do you
> mean to have mirror of the Internet locally? Probably, no. The same is
> here. Internet connection is the common requirement nowadays, but if you
> don't have one, you definitely need to have a kind of local copy.
>
> Vladimir Kozhukalov
>
> On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin 
> wrote:
>
>> Igor
>>
>> Having poor access to the internet is a regular use case which we must
>> support. This is not a crazy requirement. Not having full ISO makes cloud
>> setup harder to complete. Even more, not having hard requirement to create
>> a mirror will detract newcomers. I can say that if I were a user and saw a
>> requirement to create mirror I would not try the product with comparison to
>> the case when I can get a full ISO with all the stuff I need.
>>
>> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Guys,
>>>
>>> I really appreciate your opinions on whether Fuel should be all
>>> inclusive or not. But the original topic of this thread is different. I
>>> personally think that in 2015 it is not a big deal to make the master node
>>> able to access any online host (even taking into account paranoid security
>>> policies). It is just a matter of network engineering. But it is completely
>>> out of the scope. What I am suggesting is to align the way how we treat
>>> different repos, whether upstream or MOS. What I am working on right now is
>>> I am trying to make Fuel build and delivery approach really flexible. That
>>> means we need to have as little non-standard ways/hacks/approaches/options
>>> as possible.
>>>
>>> > Why can't we make this optional in the build system? It should be easy
>>> to implement, is not it?
>>>
>>> That is exactly what I am trying to do (make it optional). But I don't
>>> want it to be yet another boolean variable for this particular thing (MOS
>>> repo). We have working approach for dealing with repos. Repos can either
>>> online or local mirrors. We have a tool for making local mirrors
>>> (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
>>> deploy OpenStack, because he/she still needs upstream to be available.
>>> Anyway, the user is still forced to do some additional actions. Again, we
>>> have plans to improve the quality and UX of fuel-createmirror.
>>>
>>> Yet another thing I don't want to be on the master node is a bunch of
>>> MOS repos directories named like
>>> /var/www/nailgun/2015.1-7.0
>>> /var/www/nailgun/2014.4-6.1
>>> with links like
>>> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
>>> What does this link mean? Even Fuel developers can be confused. It is
>>> scary to imagine what users think of it :-) Why should Nailgun and upgrade
>>> script manage that kind of storage in this exact kind of format? A long
>>> time ago people invented RPM/DEB repositories, tools to manage them and
>>> structure for versioning them. We have Perestoika for that and we have
>>> plans to put all package/mirror related tools in one place (
>>> github.com/stackforge/fuel-mirror) and make all these tools available
>>> out of Fuel CI. So, users will be able to easily build their own packages,
>>> clone necessary repos and manage them in the way which is standard in the
>>> industry. However, it is out of the scope of the letter.
>>>
>>> I also don't like the idea of putting MOS repo on the ISO by default
>>> because it encourages people thing that ISO is the way of distributing MOS.
>>> ISO should be nothing more than just a way of installing Fuel from scratch.
>>> MOS should be distributed via MOS repos. Fuel is available as RPM package
>>> in RPM MOS repo.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky >> > wrote:
>>>
 Mike,

 > still not exactly true for some large enterprises. Due to all the
 security, etc.,
 > there are sometimes VPNs / proxies / firewalls with very low
 throughput.

 It's their problem, and their policies. We can't and shouldn't handle
 all possible cases. If some enterprise has "no Internet" policy, I bet

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Vladimir,

* We can not put upstream Ubuntu on ISO by default and publish it. We just
can not and thus won't do that.
* If a user wants to have all inclusive ISO, he/she will do it on his/her
own, on his/her own machine, probably using publicly available Fuel tools,
but not using Fuel CI/CD.

I am suggesting nothing more than to make things simpler so that I am able
to implement such tools that could be used to easily build all
inclusive/not inclusive/empty/whatever ISO if one would like to do it.


Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 6:18 PM, Vladimir Kuklin 
wrote:

> Folks
>
> I guess I need to get you on-site to deploy something at our user's
> datacenter. I do want to be able to download an ISO which contains all
> packages. This may not be the primary artifact of our software suite, but
> we need to have this opportunity to build full ISO with ALL components.
> Please, do not narrow down our feature set just by thinking that users do
> not need something because we are reluctant to implement this. Just believe
> me - users need this opportunity in a lot of deployment cases. It is not
> hard to implement it. We do not need to set this as a default option, but
> we need to have it. That is my point.
>
> On Thu, Sep 10, 2015 at 5:40 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Vladimir,
>>
>> * We don't have full ISO anyway
>> * We don't require to create mirror. When you launch your browser, do you
>> mean to have mirror of the Internet locally? Probably, no. The same is
>> here. Internet connection is the common requirement nowadays, but if you
>> don't have one, you definitely need to have a kind of local copy.
>>
>> Vladimir Kozhukalov
>>
>> On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Igor
>>>
>>> Having poor access to the internet is a regular use case which we must
>>> support. This is not a crazy requirement. Not having full ISO makes cloud
>>> setup harder to complete. Even more, not having hard requirement to create
>>> a mirror will detract newcomers. I can say that if I were a user and saw a
>>> requirement to create mirror I would not try the product with comparison to
>>> the case when I can get a full ISO with all the stuff I need.
>>>
>>> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
 Guys,

 I really appreciate your opinions on whether Fuel should be all
 inclusive or not. But the original topic of this thread is different. I
 personally think that in 2015 it is not a big deal to make the master node
 able to access any online host (even taking into account paranoid security
 policies). It is just a matter of network engineering. But it is completely
 out of the scope. What I am suggesting is to align the way how we treat
 different repos, whether upstream or MOS. What I am working on right now is
 I am trying to make Fuel build and delivery approach really flexible. That
 means we need to have as little non-standard ways/hacks/approaches/options
 as possible.

 > Why can't we make this optional in the build system? It should be
 easy to implement, is not it?

 That is exactly what I am trying to do (make it optional). But I don't
 want it to be yet another boolean variable for this particular thing (MOS
 repo). We have working approach for dealing with repos. Repos can either
 online or local mirrors. We have a tool for making local mirrors
 (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
 deploy OpenStack, because he/she still needs upstream to be available.
 Anyway, the user is still forced to do some additional actions. Again, we
 have plans to improve the quality and UX of fuel-createmirror.

 Yet another thing I don't want to be on the master node is a bunch of
 MOS repos directories named like
 /var/www/nailgun/2015.1-7.0
 /var/www/nailgun/2014.4-6.1
 with links like
 /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
 What does this link mean? Even Fuel developers can be confused. It is
 scary to imagine what users think of it :-) Why should Nailgun and upgrade
 script manage that kind of storage in this exact kind of format? A long
 time ago people invented RPM/DEB repositories, tools to manage them and
 structure for versioning them. We have Perestoika for that and we have
 plans to put all package/mirror related tools in one place (
 github.com/stackforge/fuel-mirror) and make all these tools available
 out of Fuel CI. So, users will be able to easily build their own packages,
 clone necessary repos and manage them in the way which is standard in the
 industry. However, it is out of the scope of the letter.

 I also don't like the idea of putting MOS repo on the ISO by default
 because it encourages people thing that ISO is the 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Dmitry,

Thanks a lot. That is exactly what I mean. fuel-createmirror can be used by
a user during building ISO, after deployment, never and whenever he/she
wants. Standard approach for all repos. That is it. We just don't need to
put DEB MOS repo on ISO by default, because it makes little sense if
upstream repos are still online.



Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 7:58 PM, Dmitry Pyzhov  wrote:

> Guys,
>
> looks like you’ve started to talk about different things. As I see,
> original proposal was: stop treat MOS DEB repo as a special case and use
> the same flow for all repos. Your use case does not contradict it.
>
> Moreover, it requires standard flow for all repos. ‘Put everything on the
> ISO’ use case should be implemented as a new feature. It is a matter of
> running fuel-createmirror script during ISO build and usage of it during
> master node deployment. It definitely should use mirror as a single object.
> And this object should be compatible with result of the fuel-createmirror
> script usage.
>
> On 10 Sep 2015, at 18:18, Vladimir Kuklin  wrote:
>
> Folks
>
> I guess I need to get you on-site to deploy something at our user's
> datacenter. I do want to be able to download an ISO which contains all
> packages. This may not be the primary artifact of our software suite, but
> we need to have this opportunity to build full ISO with ALL components.
> Please, do not narrow down our feature set just by thinking that users do
> not need something because we are reluctant to implement this. Just believe
> me - users need this opportunity in a lot of deployment cases. It is not
> hard to implement it. We do not need to set this as a default option, but
> we need to have it. That is my point.
>
> On Thu, Sep 10, 2015 at 5:40 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Vladimir,
>>
>> * We don't have full ISO anyway
>> * We don't require to create mirror. When you launch your browser, do you
>> mean to have mirror of the Internet locally? Probably, no. The same is
>> here. Internet connection is the common requirement nowadays, but if you
>> don't have one, you definitely need to have a kind of local copy.
>>
>> Vladimir Kozhukalov
>>
>> On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Igor
>>>
>>> Having poor access to the internet is a regular use case which we must
>>> support. This is not a crazy requirement. Not having full ISO makes cloud
>>> setup harder to complete. Even more, not having hard requirement to create
>>> a mirror will detract newcomers. I can say that if I were a user and saw a
>>> requirement to create mirror I would not try the product with comparison to
>>> the case when I can get a full ISO with all the stuff I need.
>>>
>>> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
 Guys,

 I really appreciate your opinions on whether Fuel should be all
 inclusive or not. But the original topic of this thread is different. I
 personally think that in 2015 it is not a big deal to make the master node
 able to access any online host (even taking into account paranoid security
 policies). It is just a matter of network engineering. But it is completely
 out of the scope. What I am suggesting is to align the way how we treat
 different repos, whether upstream or MOS. What I am working on right now is
 I am trying to make Fuel build and delivery approach really flexible. That
 means we need to have as little non-standard ways/hacks/approaches/options
 as possible.

 > Why can't we make this optional in the build system? It should be
 easy to implement, is not it?

 That is exactly what I am trying to do (make it optional). But I don't
 want it to be yet another boolean variable for this particular thing (MOS
 repo). We have working approach for dealing with repos. Repos can either
 online or local mirrors. We have a tool for making local mirrors
 (fuel-createmirror). Even if we put MOS on the ISO, a user still can not
 deploy OpenStack, because he/she still needs upstream to be available.
 Anyway, the user is still forced to do some additional actions. Again, we
 have plans to improve the quality and UX of fuel-createmirror.

 Yet another thing I don't want to be on the master node is a bunch of
 MOS repos directories named like
 /var/www/nailgun/2015.1-7.0
 /var/www/nailgun/2014.4-6.1
 with links like
 /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
 What does this link mean? Even Fuel developers can be confused. It is
 scary to imagine what users think of it :-) Why should Nailgun and upgrade
 script manage that kind of storage in this exact kind of format? A long
 time ago people invented RPM/DEB repositories, tools to manage them and
 structure for versioning them. We have 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Dmitry Pyzhov]

Guys,

looks like you’ve started to talk about different things. As I see, original 
proposal was: stop treat MOS DEB repo as a special case and use the same flow 
for all repos. Your use case does not contradict it.

Moreover, it requires standard flow for all repos. ‘Put everything on the ISO’ 
use case should be implemented as a new feature. It is a matter of running 
fuel-createmirror script during ISO build and usage of it during master node 
deployment. It definitely should use mirror as a single object. And this object 
should be compatible with result of the fuel-createmirror script usage.

> On 10 Sep 2015, at 18:18, Vladimir Kuklin  wrote:
> 
> Folks
> 
> I guess I need to get you on-site to deploy something at our user's 
> datacenter. I do want to be able to download an ISO which contains all 
> packages. This may not be the primary artifact of our software suite, but we 
> need to have this opportunity to build full ISO with ALL components. Please, 
> do not narrow down our feature set just by thinking that users do not need 
> something because we are reluctant to implement this. Just believe me - users 
> need this opportunity in a lot of deployment cases. It is not hard to 
> implement it. We do not need to set this as a default option, but we need to 
> have it. That is my point.
> 
> On Thu, Sep 10, 2015 at 5:40 PM, Vladimir Kozhukalov 
> > wrote:
> Vladimir,
> 
> * We don't have full ISO anyway
> * We don't require to create mirror. When you launch your browser, do you 
> mean to have mirror of the Internet locally? Probably, no. The same is here. 
> Internet connection is the common requirement nowadays, but if you don't have 
> one, you definitely need to have a kind of local copy.
> 
> Vladimir Kozhukalov
> 
> On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin  > wrote:
> Igor
> 
> Having poor access to the internet is a regular use case which we must 
> support. This is not a crazy requirement. Not having full ISO makes cloud 
> setup harder to complete. Even more, not having hard requirement to create a 
> mirror will detract newcomers. I can say that if I were a user and saw a 
> requirement to create mirror I would not try the product with comparison to 
> the case when I can get a full ISO with all the stuff I need.
> 
> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov 
> > wrote:
> Guys, 
> 
> I really appreciate your opinions on whether Fuel should be all inclusive or 
> not. But the original topic of this thread is different. I personally think 
> that in 2015 it is not a big deal to make the master node able to access any 
> online host (even taking into account paranoid security policies). It is just 
> a matter of network engineering. But it is completely out of the scope. What 
> I am suggesting is to align the way how we treat different repos, whether 
> upstream or MOS. What I am working on right now is I am trying to make Fuel 
> build and delivery approach really flexible. That means we need to have as 
> little non-standard ways/hacks/approaches/options as possible. 
> 
> > Why can't we make this optional in the build system? It should be easy to 
> > implement, is not it?
> 
> That is exactly what I am trying to do (make it optional). But I don't want 
> it to be yet another boolean variable for this particular thing (MOS repo). 
> We have working approach for dealing with repos. Repos can either online or 
> local mirrors. We have a tool for making local mirrors (fuel-createmirror). 
> Even if we put MOS on the ISO, a user still can not deploy OpenStack, because 
> he/she still needs upstream to be available. Anyway, the user is still forced 
> to do some additional actions. Again, we have plans to improve the quality 
> and UX of fuel-createmirror. 
> 
> Yet another thing I don't want to be on the master node is a bunch of MOS 
> repos directories named like 
> /var/www/nailgun/2015.1-7.0 
> /var/www/nailgun/2014.4-6.1 
> with links like
> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
> What does this link mean? Even Fuel developers can be confused. It is scary 
> to imagine what users think of it :-) Why should Nailgun and upgrade script 
> manage that kind of storage in this exact kind of format? A long time ago 
> people invented RPM/DEB repositories, tools to manage them and structure for 
> versioning them. We have Perestoika for that and we have plans to put all 
> package/mirror related tools in one place (github.com/stackforge/fuel-mirror 
> ) and make all these tools 
> available out of Fuel CI. So, users will be able to easily build their own 
> packages, clone necessary repos and manage them in the way which is standard 
> in the industry. However, it is out of the scope of the letter. 
> 
> I also don't like 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Alex Schultz]

Hey Vladimir,


>
> The idea is to remove MOS DEB repo from the Fuel master node by default
> and use online MOS repo instead. Pros of such an approach are:
>
> 0) Reduced requirement for the master node minimal disk space
>

Is this a problem? How much disk space is saved If I have to go create a
local mirror via fuel-createmirror?


> 1) There won't be such things in like [1] and [2], thus less complicated
> flow, less errors, easier to maintain, easier to understand, easier to
> troubleshoot
> 2) If one wants to have local mirror, the flow is the same as in case of
> upstream repos (fuel-createmirror), which is clrear for a user to
> understand.
>

>From the issues I've seen,  fuel-createmirror isn't very straight forward
and has some issues making it a bad UX.


>
> Many people still associate ISO with MOS, but it is not true when using
> package based delivery approach.
>
> It is easy to define necessary repos during deployment and thus it is easy
> to control what exactly is going to be installed on slave nodes.
>
> What do you guys think of it?
>
>
>
Reliance on internet connectivity has been an issue since 6.1. For many
large users, complete access to the internet is not available or not
desired.  If we want to continue down this path, we need to improve the
tools to setup the local mirror and properly document what urls/ports/etc
need to be available for the installation of openstack and any mirror
creation process.  The ideal thing is to have an all-in-one CD similar to a
live cd that allows a user to completely try out fuel wherever they want
with out further requirements of internet access.  If we don't want to
continue with that, we need to do a better job around providing the tools
for a user to get up and running in a timely fashion.  Perhaps providing an
net-only iso and an all-included iso would be a better solution so people
will have their expectations properly set up front?

-Alex


>
> Vladimir Kozhukalov
>
> On Tue, Sep 8, 2015 at 4:53 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> The idea is to remove MOS DEB repo from the Fuel master node by default
>> and use online MOS repo instead. Pros of such an approach are:
>>
>> 0) Reduced requirement for the master node minimal disk space
>> 1) There won't be such things in like [1] and [2], thus less complicated
>> flow, less errors, easier to maintain, easier to understand, easier to
>> troubleshoot
>> 2) If one wants to have local mirror, the flow is the same as in case of
>> upstream repos (fuel-createmirror), which is clrear for a user to
>> understand.
>>
>> Many people still associate ISO with MOS
>>
>>
>>
>>
>>
>> [1]
>> https://github.com/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419
>> [2]
>> https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115
>>
>>
>> Vladimir Kozhukalov
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Adam Lawson]

We thought about doing this as well and opted for a local repo, at least
for now. If you want to offer an online repo, I think it could be useful to
allow either scenario.

Just a thought from your friendly neighbors here. ; )

/adam
On Sep 8, 2015 7:03 AM, "Vladimir Kozhukalov" 
wrote:

> Sorry, fat fingers => early sending.
>
> =
> Dear colleagues,
>
> The idea is to remove MOS DEB repo from the Fuel master node by default
> and use online MOS repo instead. Pros of such an approach are:
>
> 0) Reduced requirement for the master node minimal disk space
> 1) There won't be such things in like [1] and [2], thus less complicated
> flow, less errors, easier to maintain, easier to understand, easier to
> troubleshoot
> 2) If one wants to have local mirror, the flow is the same as in case of
> upstream repos (fuel-createmirror), which is clrear for a user to
> understand.
>
> Many people still associate ISO with MOS, but it is not true when using
> package based delivery approach.
>
> It is easy to define necessary repos during deployment and thus it is easy
> to control what exactly is going to be installed on slave nodes.
>
> What do you guys think of it?
>
>
>
> Vladimir Kozhukalov
>
> On Tue, Sep 8, 2015 at 4:53 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> The idea is to remove MOS DEB repo from the Fuel master node by default
>> and use online MOS repo instead. Pros of such an approach are:
>>
>> 0) Reduced requirement for the master node minimal disk space
>> 1) There won't be such things in like [1] and [2], thus less complicated
>> flow, less errors, easier to maintain, easier to understand, easier to
>> troubleshoot
>> 2) If one wants to have local mirror, the flow is the same as in case of
>> upstream repos (fuel-createmirror), which is clrear for a user to
>> understand.
>>
>> Many people still associate ISO with MOS
>>
>>
>>
>>
>>
>> [1]
>> https://github.com/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419
>> [2]
>> https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115
>>
>>
>> Vladimir Kozhukalov
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Yaguang Tang]

On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz  wrote:

>
> Hey Vladimir,
>
>
>>
>>
>>> 1) There won't be such things in like [1] and [2], thus less complicated
 flow, less errors, easier to maintain, easier to understand, easier to
 troubleshoot
 2) If one wants to have local mirror, the flow is the same as in case
 of upstream repos (fuel-createmirror), which is clrear for a user to
 understand.

>>>
>>> From the issues I've seen,  fuel-createmirror isn't very straight
>>> forward and has some issues making it a bad UX.
>>>
>>
>> I'd say the whole approach of having such tool as fuel-createmirror is a
>> way too naive. Reliable internet connection is totally up to network
>> engineering rather than deployment. Even using proxy is much better that
>> creating local mirror. But this discussion is totally out of the scope of
>> this letter. Currently,  we have fuel-createmirror and it is pretty
>> straightforward (installed as rpm, has just a couple of command line
>> options). The quality of this script is also out of the scope of this
>> thread. BTW we have plans to improve it.
>>
>
>
> Fair enough, I just wanted to raise the UX issues around these types of
> things as they should go into the decision making process.
>
>
>
>>
>>>
 Many people still associate ISO with MOS, but it is not true when using
 package based delivery approach.

 It is easy to define necessary repos during deployment and thus it is
 easy to control what exactly is going to be installed on slave nodes.

 What do you guys think of it?



>>> Reliance on internet connectivity has been an issue since 6.1. For many
>>> large users, complete access to the internet is not available or not
>>> desired.  If we want to continue down this path, we need to improve the
>>> tools to setup the local mirror and properly document what urls/ports/etc
>>> need to be available for the installation of openstack and any mirror
>>> creation process.  The ideal thing is to have an all-in-one CD similar to a
>>> live cd that allows a user to completely try out fuel wherever they want
>>> with out further requirements of internet access.  If we don't want to
>>> continue with that, we need to do a better job around providing the tools
>>> for a user to get up and running in a timely fashion.  Perhaps providing an
>>> net-only iso and an all-included iso would be a better solution so people
>>> will have their expectations properly set up front?
>>>
>>
>> Let me explain why I think having local MOS mirror by default is bad:
>> 1) I don't see any reason why we should treat MOS  repo other way than
>> all other online repos. A user sees on the settings tab the list of repos
>> one of which is local by default while others are online. It can make user
>> a little bit confused, can't it? A user can be also confused by the fact,
>> that some of the repos can be cloned locally by fuel-createmirror while
>> others can't. That is not straightforward, NOT fuel-createmirror UX.
>>
>
>
> I agree. The process should be the same and it should be just another
> repo. It doesn't mean we can't include a version on an ISO as part of a
> release.  Would it be better to provide the mirror on the ISO but not have
> it enabled by default for a release so that we can gather user feedback on
> this? This would include improved documentation and possibly allowing a
> user to choose their preference so we can collect metrics?
>
>
> 2) Having local MOS mirror by default makes things much more convoluted.
>> We are forced to have several directories with predefined names and we are
>> forced to manage these directories in nailgun, in upgrade script, etc. Why?
>> 3) When putting MOS mirror on ISO, we make people think that ISO is equal
>> to MOS, which is not true. It is possible to implement really flexible
>> delivery scheme, but we need to think of these things as they are
>> independent.
>>
>
>
> I'm not sure what you mean by this. Including a point in time copy on an
> ISO as a release is a common method of distributing software. Is this a
> messaging thing that needs to be addressed? Perhaps I'm not familiar with
> people referring to the ISO as being MOS.
>
>
> For large users it is easy to build custom ISO and put there what they
>> need but first we need to have simple working scheme clear for everyone. I
>> think dealing with all repos the same way is what is gonna makes things
>> simpler.
>>
>>
>
> Who is going to build a custom ISO? How does one request that? What
> resources are consumed by custom ISO creation process/request? Does this
> scale?
>
>
>
>> This thread is not about internet connectivity, it is about aligning
>> things.
>>
>>
> You are correct in that this thread is not explicitly about internet
> connectivity, but they are related. Any changes to remove a local
> repository and only provide an internet based solution makes internet
> connectivity something that needs to be 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Igor Kalnitsky]

Hello,

I agree with Vladimir - the idea of online repos is a right way to
move. In 2015 I believe we can ignore this "poor Internet connection"
reason, and simplify both Fuel and UX. Moreover, take a look at Linux
distributives - most of them fetch needed packages from the Internet
during installation, not from CD/DVD. The netboot installers are
popular, I can't even remember when was the last time I install my
Debian from the DVD-1 - I use netboot installer for years.

Thanks,
Igor


On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang  wrote:
>
>
> On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz  wrote:
>>
>>
>> Hey Vladimir,
>>
>>>
>>>
>
> 1) There won't be such things in like [1] and [2], thus less
> complicated flow, less errors, easier to maintain, easier to understand,
> easier to troubleshoot
> 2) If one wants to have local mirror, the flow is the same as in case
> of upstream repos (fuel-createmirror), which is clrear for a user to
> understand.


 From the issues I've seen,  fuel-createmirror isn't very straight
 forward and has some issues making it a bad UX.
>>>
>>>
>>> I'd say the whole approach of having such tool as fuel-createmirror is a
>>> way too naive. Reliable internet connection is totally up to network
>>> engineering rather than deployment. Even using proxy is much better that
>>> creating local mirror. But this discussion is totally out of the scope of
>>> this letter. Currently,  we have fuel-createmirror and it is pretty
>>> straightforward (installed as rpm, has just a couple of command line
>>> options). The quality of this script is also out of the scope of this
>>> thread. BTW we have plans to improve it.
>>
>>
>>
>> Fair enough, I just wanted to raise the UX issues around these types of
>> things as they should go into the decision making process.
>>
>>
>>>
>
>
> Many people still associate ISO with MOS, but it is not true when using
> package based delivery approach.
>
> It is easy to define necessary repos during deployment and thus it is
> easy to control what exactly is going to be installed on slave nodes.
>
> What do you guys think of it?
>
>

 Reliance on internet connectivity has been an issue since 6.1. For many
 large users, complete access to the internet is not available or not
 desired.  If we want to continue down this path, we need to improve the
 tools to setup the local mirror and properly document what urls/ports/etc
 need to be available for the installation of openstack and any mirror
 creation process.  The ideal thing is to have an all-in-one CD similar to a
 live cd that allows a user to completely try out fuel wherever they want
 with out further requirements of internet access.  If we don't want to
 continue with that, we need to do a better job around providing the tools
 for a user to get up and running in a timely fashion.  Perhaps providing an
 net-only iso and an all-included iso would be a better solution so people
 will have their expectations properly set up front?
>>>
>>>
>>> Let me explain why I think having local MOS mirror by default is bad:
>>> 1) I don't see any reason why we should treat MOS  repo other way than
>>> all other online repos. A user sees on the settings tab the list of repos
>>> one of which is local by default while others are online. It can make user a
>>> little bit confused, can't it? A user can be also confused by the fact, that
>>> some of the repos can be cloned locally by fuel-createmirror while others
>>> can't. That is not straightforward, NOT fuel-createmirror UX.
>>
>>
>>
>> I agree. The process should be the same and it should be just another
>> repo. It doesn't mean we can't include a version on an ISO as part of a
>> release.  Would it be better to provide the mirror on the ISO but not have
>> it enabled by default for a release so that we can gather user feedback on
>> this? This would include improved documentation and possibly allowing a user
>> to choose their preference so we can collect metrics?
>>
>>
>>> 2) Having local MOS mirror by default makes things much more convoluted.
>>> We are forced to have several directories with predefined names and we are
>>> forced to manage these directories in nailgun, in upgrade script, etc. Why?
>>> 3) When putting MOS mirror on ISO, we make people think that ISO is equal
>>> to MOS, which is not true. It is possible to implement really flexible
>>> delivery scheme, but we need to think of these things as they are
>>> independent.
>>
>>
>>
>> I'm not sure what you mean by this. Including a point in time copy on an
>> ISO as a release is a common method of distributing software. Is this a
>> messaging thing that needs to be addressed? Perhaps I'm not familiar with
>> people referring to the ISO as being MOS.
>>
>>
>>> For large users it is easy to build custom ISO and put there what they
>>> 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Alex,

The idea is to remove MOS DEB repo from the Fuel master node by default and
>> use online MOS repo instead. Pros of such an approach are:
>>
>> 0) Reduced requirement for the master node minimal disk space
>>
>
> Is this a problem? How much disk space is saved If I have to go create a
> local mirror via fuel-createmirror?
>

It is not a problem at all, but still it is pro of the proposal.


> 1) There won't be such things in like [1] and [2], thus less complicated
>> flow, less errors, easier to maintain, easier to understand, easier to
>> troubleshoot
>> 2) If one wants to have local mirror, the flow is the same as in case of
>> upstream repos (fuel-createmirror), which is clrear for a user to
>> understand.
>>
>
> From the issues I've seen,  fuel-createmirror isn't very straight forward
> and has some issues making it a bad UX.
>

I'd say the whole approach of having such tool as fuel-createmirror is a
way too naive. Reliable internet connection is totally up to network
engineering rather than deployment. Even using proxy is much better that
creating local mirror. But this discussion is totally out of the scope of
this letter. Currently,  we have fuel-createmirror and it is pretty
straightforward (installed as rpm, has just a couple of command line
options). The quality of this script is also out of the scope of this
thread. BTW we have plans to improve it.


>
>> Many people still associate ISO with MOS, but it is not true when using
>> package based delivery approach.
>>
>> It is easy to define necessary repos during deployment and thus it is
>> easy to control what exactly is going to be installed on slave nodes.
>>
>> What do you guys think of it?
>>
>>
>>
> Reliance on internet connectivity has been an issue since 6.1. For many
> large users, complete access to the internet is not available or not
> desired.  If we want to continue down this path, we need to improve the
> tools to setup the local mirror and properly document what urls/ports/etc
> need to be available for the installation of openstack and any mirror
> creation process.  The ideal thing is to have an all-in-one CD similar to a
> live cd that allows a user to completely try out fuel wherever they want
> with out further requirements of internet access.  If we don't want to
> continue with that, we need to do a better job around providing the tools
> for a user to get up and running in a timely fashion.  Perhaps providing an
> net-only iso and an all-included iso would be a better solution so people
> will have their expectations properly set up front?
>

Let me explain why I think having local MOS mirror by default is bad:
1) I don't see any reason why we should treat MOS  repo other way than all
other online repos. A user sees on the settings tab the list of repos one
of which is local by default while others are online. It can make user a
little bit confused, can't it? A user can be also confused by the fact,
that some of the repos can be cloned locally by fuel-createmirror while
others can't. That is not straightforward, NOT fuel-createmirror UX.
2) Having local MOS mirror by default makes things much more convoluted. We
are forced to have several directories with predefined names and we are
forced to manage these directories in nailgun, in upgrade script, etc. Why?
3) When putting MOS mirror on ISO, we make people think that ISO is equal
to MOS, which is not true. It is possible to implement really flexible
delivery scheme, but we need to think of these things as they are
independent.
For large users it is easy to build custom ISO and put there what they need
but first we need to have simple working scheme clear for everyone. I think
dealing with all repos the same way is what is gonna makes things simpler.

This thread is not about internet connectivity, it is about aligning things.



> -Alex
>
>
>>
>> Vladimir Kozhukalov
>>
>> On Tue, Sep 8, 2015 at 4:53 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Dear colleagues,
>>>
>>> The idea is to remove MOS DEB repo from the Fuel master node by default
>>> and use online MOS repo instead. Pros of such an approach are:
>>>
>>> 0) Reduced requirement for the master node minimal disk space
>>> 1) There won't be such things in like [1] and [2], thus less complicated
>>> flow, less errors, easier to maintain, easier to understand, easier to
>>> troubleshoot
>>> 2) If one wants to have local mirror, the flow is the same as in case of
>>> upstream repos (fuel-createmirror), which is clrear for a user to
>>> understand.
>>>
>>> Many people still associate ISO with MOS
>>>
>>>
>>>
>>>
>>>
>>> [1]
>>> https://github.com/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419
>>> [2]
>>> https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>
>>
>> __
>> OpenStack Development 

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Alex Schultz]

Hey Vladimir,


>
>
>> 1) There won't be such things in like [1] and [2], thus less complicated
>>> flow, less errors, easier to maintain, easier to understand, easier to
>>> troubleshoot
>>> 2) If one wants to have local mirror, the flow is the same as in case of
>>> upstream repos (fuel-createmirror), which is clrear for a user to
>>> understand.
>>>
>>
>> From the issues I've seen,  fuel-createmirror isn't very straight forward
>> and has some issues making it a bad UX.
>>
>
> I'd say the whole approach of having such tool as fuel-createmirror is a
> way too naive. Reliable internet connection is totally up to network
> engineering rather than deployment. Even using proxy is much better that
> creating local mirror. But this discussion is totally out of the scope of
> this letter. Currently,  we have fuel-createmirror and it is pretty
> straightforward (installed as rpm, has just a couple of command line
> options). The quality of this script is also out of the scope of this
> thread. BTW we have plans to improve it.
>


Fair enough, I just wanted to raise the UX issues around these types of
things as they should go into the decision making process.



>
>>
>>> Many people still associate ISO with MOS, but it is not true when using
>>> package based delivery approach.
>>>
>>> It is easy to define necessary repos during deployment and thus it is
>>> easy to control what exactly is going to be installed on slave nodes.
>>>
>>> What do you guys think of it?
>>>
>>>
>>>
>> Reliance on internet connectivity has been an issue since 6.1. For many
>> large users, complete access to the internet is not available or not
>> desired.  If we want to continue down this path, we need to improve the
>> tools to setup the local mirror and properly document what urls/ports/etc
>> need to be available for the installation of openstack and any mirror
>> creation process.  The ideal thing is to have an all-in-one CD similar to a
>> live cd that allows a user to completely try out fuel wherever they want
>> with out further requirements of internet access.  If we don't want to
>> continue with that, we need to do a better job around providing the tools
>> for a user to get up and running in a timely fashion.  Perhaps providing an
>> net-only iso and an all-included iso would be a better solution so people
>> will have their expectations properly set up front?
>>
>
> Let me explain why I think having local MOS mirror by default is bad:
> 1) I don't see any reason why we should treat MOS  repo other way than all
> other online repos. A user sees on the settings tab the list of repos one
> of which is local by default while others are online. It can make user a
> little bit confused, can't it? A user can be also confused by the fact,
> that some of the repos can be cloned locally by fuel-createmirror while
> others can't. That is not straightforward, NOT fuel-createmirror UX.
>


I agree. The process should be the same and it should be just another repo.
It doesn't mean we can't include a version on an ISO as part of a release.
Would it be better to provide the mirror on the ISO but not have it enabled
by default for a release so that we can gather user feedback on this? This
would include improved documentation and possibly allowing a user to choose
their preference so we can collect metrics?


2) Having local MOS mirror by default makes things much more convoluted. We
> are forced to have several directories with predefined names and we are
> forced to manage these directories in nailgun, in upgrade script, etc. Why?
> 3) When putting MOS mirror on ISO, we make people think that ISO is equal
> to MOS, which is not true. It is possible to implement really flexible
> delivery scheme, but we need to think of these things as they are
> independent.
>


I'm not sure what you mean by this. Including a point in time copy on an
ISO as a release is a common method of distributing software. Is this a
messaging thing that needs to be addressed? Perhaps I'm not familiar with
people referring to the ISO as being MOS.


For large users it is easy to build custom ISO and put there what they need
> but first we need to have simple working scheme clear for everyone. I think
> dealing with all repos the same way is what is gonna makes things simpler.
>
>

Who is going to build a custom ISO? How does one request that? What
resources are consumed by custom ISO creation process/request? Does this
scale?



> This thread is not about internet connectivity, it is about aligning
> things.
>
>
You are correct in that this thread is not explicitly about internet
connectivity, but they are related. Any changes to remove a local
repository and only provide an internet based solution makes internet
connectivity something that needs to be included in the discussion.  I just
want to make sure that we properly evaluate this decision based on end user
feedback not because we don't want to manage this from a developer
standpoint.

-Alex

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Sorry, fat fingers => early sending.

=
Dear colleagues,

The idea is to remove MOS DEB repo from the Fuel master node by default and
use online MOS repo instead. Pros of such an approach are:

0) Reduced requirement for the master node minimal disk space
1) There won't be such things in like [1] and [2], thus less complicated
flow, less errors, easier to maintain, easier to understand, easier to
troubleshoot
2) If one wants to have local mirror, the flow is the same as in case of
upstream repos (fuel-createmirror), which is clrear for a user to
understand.

Many people still associate ISO with MOS, but it is not true when using
package based delivery approach.

It is easy to define necessary repos during deployment and thus it is easy
to control what exactly is going to be installed on slave nodes.

What do you guys think of it?



Vladimir Kozhukalov

On Tue, Sep 8, 2015 at 4:53 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> The idea is to remove MOS DEB repo from the Fuel master node by default
> and use online MOS repo instead. Pros of such an approach are:
>
> 0) Reduced requirement for the master node minimal disk space
> 1) There won't be such things in like [1] and [2], thus less complicated
> flow, less errors, easier to maintain, easier to understand, easier to
> troubleshoot
> 2) If one wants to have local mirror, the flow is the same as in case of
> upstream repos (fuel-createmirror), which is clrear for a user to
> understand.
>
> Many people still associate ISO with MOS
>
>
>
>
>
> [1]
> https://github.com/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419
> [2]
> https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115
>
>
> Vladimir Kozhukalov
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Dear colleagues,

The idea is to remove MOS DEB repo from the Fuel master node by default and
use online MOS repo instead. Pros of such an approach are:

0) Reduced requirement for the master node minimal disk space
1) There won't be such things in like [1] and [2], thus less complicated
flow, less errors, easier to maintain, easier to understand, easier to
troubleshoot
2) If one wants to have local mirror, the flow is the same as in case of
upstream repos (fuel-createmirror), which is clrear for a user to
understand.

Many people still associate ISO with MOS





[1]
https://github.com/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419
[2]
https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115


Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev