Open Stack

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 <vkuklin at mirantis.com> 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 <ogelbukh at mirantis.com>
> 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 <ikalnitsky at 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 <ytang at mirantis.com> wrote:
>>> >
>>> >
>>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz <aschultz at mirantis.com>
>>> > 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 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.
>>> >
>>> >
>>> >
>>> >  +1, whatever the changes is, please keep Fuel as a tool that can
>>> > deploy
>>> > without Internet access, this is part of reason that people like it and
>>> > it's
>>> > better that other tools.
>>> >>
>>> >>
>>> >> -Alex
>>> >>
>>> >>
>>> >>
>>> >> __________________________________________________________________________
>>> >> OpenStack Development Mailing List (not for usage questions)
>>> >> Unsubscribe:
>>> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Yaguang Tang
>>> > Technical Support, Mirantis China
>>> >
>>> > Phone: +86 15210946968
>>> >
>>> >
>>> >
>>> >
>>> > __________________________________________________________________________
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuklin at mirantis.com
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>