Open Stack

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 <
vkozhukalov at 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 <ikalnitsky at mirantis.com>
> 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 <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
>> >
>>
>> __________________________________________________________________________
>> 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 <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150910/9584e963/attachment.html>