Open Stack

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 <ytang at mirantis.com> wrote:

>
>
> On Thu, Sep 10, 2015 at 1:52 PM, 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.
>>
>
> 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 <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
>>
>
>
>
> --
> 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
>
>


-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150910/e044493b/attachment.html>