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
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
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
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
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
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"
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
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
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.,
>
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
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,
* 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
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.
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
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
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’
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
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"
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
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
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
>
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
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
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,
24 matches
Mail list logo