autogenerated page like
>>>>>> https://download.pytorch.org/whl/nightly/cu101/torch_nightly.html
>>>>>>
>>>>>> Then "pip install -f URLTOPAGE mxnet" will install the latest
>> available
>>>>>> version.
>&
Mon, 2020-01-06 at 10:01 -0800, Lin Yuan wrote:
> > >>> +1 for a nightly pip with fixed name.
> > >>>
> > >>> We need this to track mxnet integration with other packages such as
> > >>> Horovod.
> > >>>
> > >>> Sam, when
gt; name?
> >>>
> >>> Thanks,
> >>>
> >>> Lin
> >>>
> >>> On Sun, Jan 5, 2020 at 7:48 PM Skalicky, Sam
> >>> mailto:sska...@amazon.com.invalid>>
> >>> wrote:
> >>>
> >>> Hi Tao,
> >>&g
ailto:sska...@amazon.com.invalid>>
>>> wrote:
>>>
>>> Hi Tao,
>>>
>>> We dont have this yet, but we did think about putting the latest
>>> wheels in
>>> a specific place in the s3 bucket so they are always updated.
>>> Initially we
>>
ic place in the s3 bucket so they are always updated.
> > Initially we
> > decided not to do this since the main MXNet CD should have been
> > fixed. But
> > since its still not fixed yet, we might try and go ahead and do
> > this.
> >
> > Sam
> >
> > On
to install the latest available build of a flavor without
> specifying
> the build date? Something like `pip install mxnet --pre`.
>
> Thanks,
> -tao
>
> -Original Message-
> From: Skalicky, Sam sska...@amazon.com.INVALID> sska...@amazon.com.INVALID<mailto:s
install mxnet --pre`.
Thanks,
-tao
-Original Message-
From: Skalicky, Sam
mailto:sska...@amazon.com.INVALID>mailto:sska...@amazon.com.INVALID>>>
Sent: Monday, January 6, 2020 2:09 AM
To:
dev@mxnet.incubator.apache.org<mailto:dev@mxnet.incubator.apache.org>mailto:dev@mxnet.
; > > > > > a specific place in the s3 bucket so they are always updated.
> > > Initially we
> > > > > > decided not to do this since the main MXNet CD should have been
> > > fixed. But
> > > > > > since its still not fixed yet, we might
; > >
> > > > > On Jan 5, 2020, at 6:02 PM, Lv, Tao A > > > > tao.a...@intel.com>> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > How to install the latest available build of a flavor without
> > s
nd go ahead and do this.
> > > >
> > > > Sam
> > > >
> > > > On Jan 5, 2020, at 6:02 PM, Lv, Tao A > > > tao.a...@intel.com>> wrote:
> > > >
> > > > Hi,
> > > >
> > > > How to install the la
> > > the build date? Something like `pip install mxnet --pre`.
> > >
> > > Thanks,
> > > -tao
> > >
> > > -Original Message-
> > > From: Skalicky, Sam > > sska...@amazon.com.INVALID>>
> > > Sent: Monday, Januar
Thanks for your detailed responses.
Having codebuild execute the recipe that is the apache repository is the
same effect and control that you would have in some service such as travis
CI. And the builds are fully reproducible. So it's under full control of
Apache the same way that any other
Correct, I'm not bothered by the s3 bucket but by way how it gets
published. It's not in Jenkins, so it's outside of the projects control.
The security design due to the restricted nodes makes sure that no third
party can gain access to these machines. They use separate caches, separate
volumes,
Marco, if you are fine publishing to an S3 bucket, what's your concern?
using a codebuild pipeline? The build logs could be push to the s3 bucket
if this is your concern.
As I said before, having binary releases in the current CI doesn't stand a
chance to pass security review as it is today, it's
Is not about Jenkins the software, is about the CI environment, which is
not secure. Last week there was crypto mining activity on the dev
environment, code can be injected on binary releases very easily. It should
be a separate instance for CD, so maybe you can facilitate that with Apache
as part
Pedro:
> binary releases from the CI jenkins as it is today is a very bad idea
since it's an unsafe environment
Can you clarify this statement? We could grant an Instance Profile to the
Jenkins master instance so that it can push artifacts to an S3 bucket.
Do you mean that virus or malware could
The risk of the current CD via Jenkins is known and was accepted as part of
adopting Jenkins. The solution for the initial issue - no longer publishing
to pypi - is to add a step to the existing CD pipeline which publishes the
package to the s3 bucket instead of pypi.
-Marco
Pedro Larroy
I understand your point. But you don't provide an alternative, and building
binary releases from the CI jenkins as it is today is a very bad idea since
it's an unsafe environment. I think it's fair to ask if you are vetoing
using codebuild for nightly releases you could provide an alternative
s3 bucket so they are always updated.
>> Initially we
>> >>> decided not to do this since the main MXNet CD should have been
>> fixed. But
>> >>> since its still not fixed yet, we might try and go ahead and do this.
>> >>>
>> >>>
t 6:02 PM, Lv, Tao A >>> tao.a...@intel.com>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> How to install the latest available build of a flavor without
> specifying
> >>> the build date? Something like `pip install mxnet -
t;>> How to install the latest available build of a flavor without specifying
>>> the build date? Something like `pip install mxnet --pre`.
>>>
>>> Thanks,
>>> -tao
>>>
>>> -Original Message-
>>> From: Skalicky, Sam >&
nal Message-
> From: Skalicky, Sam sska...@amazon.com.INVALID>>
> Sent: Monday, January 6, 2020 2:09 AM
> To: dev@mxnet.incubator.apache.org<mailto:dev@mxnet.incubator.apache.org>
> Subject: Re: Stopping nightly releases to Pypi
>
> Hi Haibin,
>
> You typed th
y, Sam
mailto:sska...@amazon.com.INVALID>>
Sent: Monday, January 6, 2020 2:09 AM
To: dev@mxnet.incubator.apache.org<mailto:dev@mxnet.incubator.apache.org>
Subject: Re: Stopping nightly releases to Pypi
Hi Haibin,
You typed the correct URLs, the cu100 build has been failing since December
30t
nightly releases to Pypi
Hi Haibin,
You typed the correct URLs, the cu100 build has been failing since December
30th but other builds have succeeded. The wheels are being delivered into a
public bucket that anyone with an AWS account can access and go poke around,
here’s the URL for web access
Hi Haibin,
You typed the correct URLs, the cu100 build has been failing since December
30th but other builds have succeeded. The wheels are being delivered into a
public bucket that anyone with an AWS account can access and go poke around,
here’s the URL for web access:
Apache only cares about source releases as far as official releases are
concerned. But Apache also cares about it's brand and image. You are right
that anybody can compile an Apache project and distribute it, but it's
under the PMCs control what can be advertised as official. This includes
the
I was trying the nightly builds, but none of them is available:
pip3 install
https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2020-01-01/dist/mxnet_cu100-1.6.0b20200101-py2.py3-none-manylinux1_x86_64.whl
--user
pip3 install
Hey Marco.
As far as I have learned from other Apache mailing lists while lurking is
that Apache only cares about making source releases, binaries are a
courtesy to users that some projects decide to do, but I'm not sure I
understand your concerns regarding the PMC and what exactly are you
Regarding your point of finding somebody to maintain the solution: At
Apache we usually retire things if there's no maintainer, since that
indicates that the feature/system is not of enough interest to warrant
maintenance - otherwise, someone would step up.
While assistance in the form of a fix
Sam, while I understand that this solution was developed out of necessity,
my question why a new system has been developed instead of fixing the
existing one or adapting the solution. CodeBuild is a scheduler in the same
fashion as Jenkins is. It runs code. So you can adapt it to Jenkins without
Hi Chris,
It really came down to some developers wanting to use regular nightly pip
builds. The CD system wasn’t working (stopped about 10/25/2019) so the nightly
builds that were available were stale. We put together a system to build the
nightlies quickly for our own use, and started putting
I am curious what reasoning went into a non-community entity deploying what
is effectively de-facto public builds of an Apache project, "temporary" or
not. Was this discussed on dev list? Btw, I don't buy this "temporary"
thing -- "temporary" has a bad habit of becoming "permanent". Also, I
Hi Marco,
I don’t think anyone wants only Amazonians to control access to the system.
However, no one has stepped up to help develop one that the community can
maintain. Sure there has been some work here or there but nothing consistent. I
think what we’re waiting for is someone to volunteer
Agree, but the question how a non Amazonian is able to maintain and access
the system is still open. As it stands right now, the community has taken a
step back and loses some control if we continue down that road.
I personally am disapproving of that approach since committers are no
longer in
CD should be separate from CI for security reasons in any case.
On Sat, Dec 7, 2019 at 10:04 AM Marco de Abreu
wrote:
> Could you elaborate how a non-Amazonian is able to access, maintain and
> review the CodeBuild pipeline? How come we've diverted from the community
> agreed-on standard where
.org
> Cc: d...@mxnet.apache.org
> Subject: Re: Stopping nightly releases to Pypi
>
> Shall we update the website installation page with nightly build information
> as well (after we figure out the CD details)?
>
> Best,
> Haibin
>
> On Tue, Dec 10, 2019 at 10:15 PM
Shall we update the website installation page with nightly build
information as well (after we figure out the CD details)?
Best,
Haibin
On Tue, Dec 10, 2019 at 10:15 PM Lausen, Leonard
wrote:
> Not yet. As a community, we first need to add the nightly build hosting
> feature
> to the community
Not yet. As a community, we first need to add the nightly build hosting feature
to the community run CD and then we can add the page so that the exact date
doesn't need to be specified.
I'm not sure what steps are required for this. Do we need to host the artifacts
on Apache's infrastructure? Or
Is there a way to install the latest nightly package without having to
specify exact date?
Thanks,
Lin
On Sun, Dec 8, 2019 at 6:13 PM Lausen, Leonard
wrote:
> From Shanghai, the closest endpoint (automatically chosen endpoint) is in
> Tokyo
> and download speed for mxnet-mkl was on average
From Shanghai, the closest endpoint (automatically chosen endpoint) is in Tokyo
and download speed for mxnet-mkl was on average 1.7 MB/s with a maximum of 5
MB/s during my test.
On Sun, 2019-12-08 at 01:30 +, Sheng Zha wrote:
> > Heres a set of links for today’s builds
> >
> > (Plain mxnet,
Thanks Sheng,
Looks like 12/8 builds are working as expected too:
(Plain mxnet, no mkl no cuda)
https://repo.mxnet.io/dist/2019-12-08/dist/mxnet-1.6.0b20191208-py2.py3-none-manylinux1_x86_64.whl
(mxnet-mkl)
> Heres a set of links for today’s builds
>
> (Plain mxnet, no mkl no cuda)
> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-07/dist/mxnet-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> (mxnet-mkl)
>
Could you elaborate how a non-Amazonian is able to access, maintain and
review the CodeBuild pipeline? How come we've diverted from the community
agreed-on standard where the public Jenkins serves for the purpose of
testing and releasing MXNet? I'd be curious about the issues you're
encountering
Hi MXNet Community,
We have been working on getting nightly builds fixed and made available again.
We’ve made another system using AWS CodeBuild & S3 to work around the problems
with Jenkins CI, PyPI, etc. It is currently building all the flavors and
publishing to an S3 bucket here:
We don't loose pip by hosting on S3. We just don't host nightly releases on Pypi
servers and mirror them to several hundred mirrors immediately after each build
is published which is very expensive for the Pypi project.. People can still
install the nightly builds with pip by specifying the -f
Are weekly releases an option? It was brought up as concern that we might
lose pip as a pretty common distribution channel where people consume
nightly builds. I don't feel like that concern has been properly addressed
so far.
-Marco
Lausen, Leonard schrieb am Mi., 4. Dez. 2019,
04:09:
> As a
As a simple POC to test distribution, you can try installing MXNet based on
these 3 URLs:
pip install --no-cache-dir
https://mxnet-dev.s3.amazonaws.com/mxnet_cu101-1.5.1.post0-py2.py3-none-manylinux1_x86_64.whl
pip install --no-cache-dir
CloudFront launched endpoints in Hong Kong during 2019. Based on my tests, they
have excellent connectivity to mainland China [1]. Thus we don't need to roll
our own geo-location based DNS server solution at this moment (though the great
firewall policy may change and we need to adapt).
Best
This has the following effect:
- the unfortunate group of user whose GPUs' SMs were removed would be
sacrificed so that import of mxnet on their machine would take quite some time
on the order of hours. we don't have the usage information to guide which SMs
to drop.
- it would cut down our
What about cutting down on SMs as recommended by Kellen?
Sheng Zha schrieb am Di., 3. Dez. 2019, 20:15:
> This is certainly one way to do it. However, the binary size limits our
> ability to publish pypi. So assuming that we want to have our binary on
> pypi still, we'd have to convince pypa to
This is certainly one way to do it. However, the binary size limits our ability
to publish pypi. So assuming that we want to have our binary on pypi still,
we'd have to convince pypa to raise our limits. Thus, it seems to me that this
hypothetical vote with respect to stopping nightly publish
Excellent! Could we maybe come up with a POC and a quick writeup and then
start a proper vote after everyone verified that it covers their use-cases?
-Marco
Sheng Zha schrieb am Di., 3. Dez. 2019, 19:24:
> Yes, there is. We can also make it easier to access by using a
> geo-location based DNS
Yes, there is. We can also make it easier to access by using a geo-location
based DNS server so that China users are directed to that local mirror. The
rest of the world is already covered by the global cloudfront.
-sz
On 2019/12/03 18:22:22, Marco de Abreu wrote:
> Isn't there an s3
Isn't there an s3 endpoint in Beijing?
It seems like this topic still warrants some discussion and thus I'd prefer
if we don't move forward with lazy consensus.
-Marco
Tao Lv schrieb am Di., 3. Dez. 2019, 14:31:
> * For pypi, we can use mirrors.
>
> On Tue, Dec 3, 2019 at 9:28 PM Tao Lv
* For pypi, we can use mirrors.
On Tue, Dec 3, 2019 at 9:28 PM Tao Lv wrote:
> As we have many users in China, I'm considering the accessibility of S3.
> For pip, we can mirrors.
>
> On Tue, Dec 3, 2019 at 3:24 PM Lausen, Leonard
> wrote:
>
>> I would like to remind everyone that lazy
As we have many users in China, I'm considering the accessibility of S3.
For pip, we can mirrors.
On Tue, Dec 3, 2019 at 3:24 PM Lausen, Leonard
wrote:
> I would like to remind everyone that lazy consensus is assumed if no
> objections
> are raised before 2019-12-05 at 05:42 UTC. There has been
I would like to remind everyone that lazy consensus is assumed if no objections
are raised before 2019-12-05 at 05:42 UTC. There has been some discussion about
the proposal, but to my understanding no objections were raised.
If the proposal is accepted, MXNet releases would be installed via
we can once again provide the whole link, but getting directly
> > > from
> > > pip is the familiar experience for most devs.
> > >
> > > Yes, 1.6 is the target release, but I don't see a world where the team can
> > > create new operators, and then ge
;> ________
>> From: Lausen, Leonard
>> Sent: Sunday, December 1, 2019 10:08 PM
>> To: dev@mxnet.incubator.apache.org
>> Cc: Kamakoti, Balaji
>> Subject: Re: Stopping nightly releases to Pypi
>>
>> If we decide to do weekly pre
Leonard
> Sent: Sunday, December 1, 2019 10:08 PM
> To: dev@mxnet.incubator.apache.org
> Cc: Kamakoti, Balaji
> Subject: Re: Stopping nightly releases to Pypi
>
> If we decide to do weekly pre-release builds to Pypi, what's the benefit? To
> catch bugs and pinpoint when they we
Quoting Dustin from Pypi: "Hi folks, this is a really big ask. The mxnet-*
projects already represent a huge portion of PyPI's total size on disk and in
terms of bandwidth. Per https://pypi.org/stats/, the mxnet-* projects total more
than 1.5TB of PyPI's 6.5TB total size."
Given these numbers,
@mxnet.incubator.apache.org
Cc: Kamakoti, Balaji
Subject: Re: Stopping nightly releases to Pypi
If we decide to do weekly pre-release builds to Pypi, what's the benefit? To
catch bugs and pinpoint when they were introduced, having weekly builds may be
too coarse. So people would likely prefer the nightly
If we decide to do weekly pre-release builds to Pypi, what's the benefit? To
catch bugs and pinpoint when they were introduced, having weekly builds may be
too coarse. So people would likely prefer the nightly releases and install them
from S3 via: pip install --pre mxnet-cu101 -f
Makes sense to me to release nightlies to s3 only. Can we reduce size by
cutting down on the SMs we release? Was the main complaint around cuda release
sizes?
On Dec 1, 2019 9:43 PM, "Lausen, Leonard" wrote:
Hi MXNet Community,
since more than 2 months our binary Python nightly releases
Hi Leonard,
Is there any reason why we shouldn't take both options? Ie we do weekly build
on PyPi and provide the s3 option. I would be inclined to make sure we provide
as many avenues as possible to reduce friction for developers. The d2l.ai book
by Alex Smola is attracting a community that
65 matches
Mail list logo
